Re: Port of Niels Provos's file descriptor allocation code
At 1:32 AM +0100 2003/11/29, Dag-Erling Smørgrav wrote: What exactly would be the point? If this is the OpenBSD fdalloc code, recent widely-publicized benchmarks have shown it to be inferior to ours. Perhaps you should concentrate on improving vm_map_find() and vm_map_findspace() performance instead? Perhaps the implementation on OpenBSD may be worse than ours, but it may add features that help improve our performance further. Certainly, both issues should be checked as broadly as possible. -- Brad Knowles, <[EMAIL PROTECTED]> "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, Historical Review of Pennsylvania. GCS/IT d+(-) s:+(++)>: a C++(+++)$ UMBSHI$ P+>++ L+ !E-(---) W+++(--) N+ !w--- O- M++ V PS++(+++) PE- Y+(++) PGP>+++ t+(+++) 5++(+++) X++(+++) R+(+++) tv+(+++) b+() DI+() D+(++) G+() e++> h--- r---(+++)* z(+++) ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 40% slowdown with dynamic /bin/sh
At 2:48 PM -0800 2003/11/25, Matthew Dillon wrote: What I am advocating is that FreeBSD-5 not marginalize and restrict (make less flexible) basic infrastructure in order to get other infrastructure working. If you've got working, debugged code that works in the manner you are espousing, and still achieves the same goal of making NSS and PAM work everywhere, I'm sure we'd all love to see it. In the absence of any code contribution to the contrary, I see no alternative than the method that has been selected. Sure, it's not great. Sure, it's slower (more or less, depending on which benchmarks you believe). But it is the best implementation that was available, and this is -CURRENT, where things are expected to periodically be in a state of flux while major changes are underway. -- Brad Knowles, <[EMAIL PROTECTED]> "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, Historical Review of Pennsylvania. GCS/IT d+(-) s:+(++)>: a C++(+++)$ UMBSHI$ P+>++ L+ !E-(---) W+++(--) N+ !w--- O- M++ V PS++(+++) PE- Y+(++) PGP>+++ t+(+++) 5++(+++) X++(+++) R+(+++) tv+(+++) b+() DI+() D+(++) G+() e++> h--- r---(+++)* z(+++) ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 40% slowdown with dynamic /bin/sh
At 11:50 AM -0800 2003/11/25, Matthew Dillon wrote: ... Or you can build an IPC mechanism that implements the PAM functionality and then have programs which would otherwise use PAM instead use the IPC mechanism. Which is the whole point of having the IPC mechanism in the first place. That all sounds wonderful! So, when are you going to deliver this fully functioning and debugged code for inclusion in FreeBSD-5.2? -- Brad Knowles, <[EMAIL PROTECTED]> "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, Historical Review of Pennsylvania. GCS/IT d+(-) s:+(++)>: a C++(+++)$ UMBSHI$ P+>++ L+ !E-(---) W+++(--) N+ !w--- O- M++ V PS++(+++) PE- Y+(++) PGP>+++ t+(+++) 5++(+++) X++(+++) R+(+++) tv+(+++) b+() DI+() D+(++) G+() e++> h--- r---(+++)* z(+++) ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Unfortunate dynamic linking for everything
At 8:59 PM -0500 2003/11/24, Andrew Gallatin wrote: Of course not. Nobody in their right mind uses csh for scripting. To my great horror, csh is used in most of the DNS debugging and many of the log-processing scripts that I have inherited. One of these days, I will finally live up to my threat of importing all this functionality into other programs that use other languages (toss "doc" and incorporate that functionality into "dnswalk", etc...), but that has not happened yet. Meanwhile, I don't know that a dynamic vs. static csh does me any measurable harm -- the delays waiting for responses from nameservers will overwhelm any local delays caused by dynamic vs. static linking. -- Brad Knowles, <[EMAIL PROTECTED]> "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, Historical Review of Pennsylvania. GCS/IT d+(-) s:+(++)>: a C++(+++)$ UMBSHI$ P+>++ L+ !E-(---) W+++(--) N+ !w--- O- M++ V PS++(+++) PE- Y+(++) PGP>+++ t+(+++) 5++(+++) X++(+++) R+(+++) tv+(+++) b+() DI+() D+(++) G+() e++> h--- r---(+++)* z(+++) ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: HEADS UP: /bin and /sbin are now dynamically linked
At 5:22 PM -0800 2003/11/22, David O'Brien wrote: Please, NO. There wasn't an FTP client available for this type of recovery pre-/rescue, there shouldn't be one now. Why? Why cut your nose off to spite your face? Even though this capability may not have existed before, why shouldn't we have it now? -- Brad Knowles, <[EMAIL PROTECTED]> "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, Historical Review of Pennsylvania. GCS/IT d+(-) s:+(++)>: a C++(+++)$ UMBSHI$ P+>++ L+ !E-(---) W+++(--) N+ !w--- O- M++ V PS++(+++) PE- Y+(++) PGP>+++ t+(+++) 5++(+++) X++(+++) R+(+++) tv+(+++) b+() DI+() D+(++) G+() e++> h--- r---(+++)* z(+++) ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Atheros Throughput TEST!
At 5:30 PM +1300 2003/10/17, Marcos Biscaysaqu wrote: We made a Throughput test with 2 different wireless card DLINK and NETGEAR , with a ftp traffic in both ways with no diference between the DLINK and NETGEAR card, Very good speed but the Freebsd AP crash after 4 min. Try pathrate and pathload. They're much better tools for getting down into the nitty-gritty details of true network throughput and bottleneck identification. Try using application-layer tools like ftp at a later stage in the testing. -- Brad Knowles, <[EMAIL PROTECTED]> "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, Historical Review of Pennsylvania. GCS/IT d+(-) s:+(++)>: a C++(+++)$ UMBSHI$ P+>++ L+ !E-(---) W+++(--) N+ !w--- O- M++ V PS++(+++) PE- Y+(++) PGP>+++ t+(+++) 5++(+++) X++(+++) R+(+++) tv+(+++) b+() DI+() D+(++) G+() e++> h--- r---(+++)* z(+++) ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ipnat memory leak?
At 6:37 PM -0600 2003/10/09, Vector wrote: However, as soon as I put it in the kernel, ipnat -l and ipnat -t became my best friends. They are incredibly useful. Okay, now that you explain it that way, it makes sense. That was very interesting to read. Thank you! -- Brad Knowles, <[EMAIL PROTECTED]> "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, Historical Review of Pennsylvania. GCS/IT d+(-) s:+(++)>: a C++(+++)$ UMBSHI$ P+>++ L+ !E-(---) W+++(--) N+ !w--- O- M++ V PS++(+++) PE- Y+(++) PGP>+++ t+(+++) 5++(+++) X++(+++) R+(+++) tv+(+++) b+() DI+() D+(++) G+() e++> h--- r---(+++)* z(+++) ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ipnat memory leak?
At 12:56 AM -0600 2003/10/09, Vector wrote: natd chokes on the latest windoze worms and I have implemented some DoS prevention/worm protection in ipnat but I'm seeing this memory leak without my improvements there at all. If it's in the kernel, ipnat is kept under control when natd would normally be sucking the CPU dry and preventing things like remote logins, very slugish updates, etc... That seems to be very odd to me. If anything, putting it in the kernel should guarantee that it could runaway with as much memory, CPU, etc... as it wanted. Could you explain a bit more about the added controls you have over this process because it's part of the kernel, as opposed to operating in user space? This is a serious question -- I don't understand, and I'd like to learn. -- Brad Knowles, <[EMAIL PROTECTED]> "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, Historical Review of Pennsylvania. GCS/IT d+(-) s:+(++)>: a C++(+++)$ UMBSHI$ P+>++ L+ !E-(---) W+++(--) N+ !w--- O- M++ V PS++(+++) PE- Y+(++) PGP>+++ t+(+++) 5++(+++) X++(+++) R+(+++) tv+(+++) b+() DI+() D+(++) G+() e++> h--- r---(+++)* z(+++) ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: D-Link DWL-520+
At 2:49 AM +0400 2003/10/06, tokza wrote: So far as I know, there are no open-source drivers for any 22mpbs card anywhere. Hm, what does "22 mbps" mean? As I know, DWL-520+ is a 802.11b-standart based card and the max speed is 11mbps as mentioned in this standart. In this case, there is only one vendor I know of that sells 802.11b equipment that is also capable of handling 22mbps speeds. That would be TI, and USR is one of their major partners. It is the TI chipset that I am talking about. See <http://www.usr.com/products/networking/wireless-product.asp?sku=USR2210>. D-Link is also a reseller of TI chipset hardware. See <http://presslink.dlink.com/pr/?prid=27>. Reading card specification I thought that "22 mbps with AirPlus series" is a kind of PR or adverticement :-) Or is this a kind of "enhanced 802.b" standart? Where can I read smth about this? See above. -- Brad Knowles, <[EMAIL PROTECTED]> "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, Historical Review of Pennsylvania. GCS/IT d+(-) s:+(++)>: a C++(+++)$ UMBSHI$ P+>++ L+ !E-(---) W+++(--) N+ !w--- O- M++ V PS++(+++) PE- Y+(++) PGP>+++ t+(+++) 5++(+++) X++(+++) R+(+++) tv+(+++) b+() DI+() D+(++) G+() e++> h--- r---(+++)* z(+++) ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: D-Link DWL-520+
At 12:31 AM +0400 2003/10/06, tokza wrote: If it's not supported, I'm afraid there's no any 22mbps card supported by freebsd. So far as I know, there are no open-source drivers for any 22mpbs card anywhere. A friend of mine does Linux driver development, in particular for wireless networking cards. He's been trying to get specs for 22mbps cards for years, and everything from every vendor requires NDA, and the OEM manufacturer won't even talk to him. If you find any open-source drivers for any 22mbps cards under any OS, please let me know. -- Brad Knowles, <[EMAIL PROTECTED]> "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, Historical Review of Pennsylvania. GCS/IT d+(-) s:+(++)>: a C++(+++)$ UMBSHI$ P+>++ L+ !E-(---) W+++(--) N+ !w--- O- M++ V PS++(+++) PE- Y+(++) PGP>+++ t+(+++) 5++(+++) X++(+++) R+(+++) tv+(+++) b+() DI+() D+(++) G+() e++> h--- r---(+++)* z(+++) ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Support for 3com 3CRWE154G72 wireless 11g card
At 2:02 AM -0700 2003/10/04, Johan Petersson wrote: I have not found any reliable information about which chipset is used, but one page with a Linux 11g driver suggests it might be an Intersil ISL38xx, perhaps ISL3890. They claim that their driver works fine. So far as I know, only the Atheros chipset has any support under *BSD. Broadcom won't release the details of their hardware access layer (HAL) except under NDA. Are there any other 802.11g chipsets? -- Brad Knowles, <[EMAIL PROTECTED]> "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, Historical Review of Pennsylvania. GCS/IT d+(-) s:+(++)>: a C++(+++)$ UMBSHI$ P+>++ L+ !E-(---) W+++(--) N+ !w--- O- M++ V PS++(+++) PE- Y+(++) PGP>+++ t+(+++) 5++(+++) X++(+++) R+(+++) tv+(+++) b+() DI+() D+(++) G+() e++> h--- r---(+++)* z(+++) ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Fixing -pthreads (Re: ports and -current)
At 7:35 PM -0400 2003/09/23, Daniel Eischen wrote: The applications is free to link to whatever it wants; we're not changing that. If it wants to link to 1:1 libthr or whatever, then it had better be sure to use -lthr because -pthread won't do it regardless of whether it is a NOOP or not. It strikes me that the compiler and linker should be able to detect -lthr vs. -lpthread vs. -lksethread (or whatever) on the command line, and if they see something like that to just DTRT with regards to a -pthread as well. Contrariwise, if there is a -pthread and no corresponding -lthr, -lpthread, or other thread library linkage that is explicitly specified, then we should be able to go through pmap.conf and figure out what the default "right thing" is that should be done. What am I missing? Making -pthread a NOOP _would_ (*) break the application in the link stage; it would be obvious when the application failed to link with lots of unresolved pthread symbols. (*) Unless we want to support LD_PRELOAD being able to change the threads library. That would seem to be another reasonable option. -- Brad Knowles, <[EMAIL PROTECTED]> "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, Historical Review of Pennsylvania. GCS/IT d+(-) s:+(++)>: a C++(+++)$ UMBSHI$ P+>++ L+ !E-(---) W+++(--) N+ !w--- O- M++ V PS++(+++) PE- Y+(++) PGP>+++ t+(+++) 5++(+++) X++(+++) R+(+++) tv+(+++) b+() DI+() D+(++) G+() e++> h--- r---(+++)* z(+++) ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: The bikeshed T-shirt
At 1:29 AM -0400 2003/09/21, Daniel Eischen wrote: Can you add a "no -pthread" symbol to it? I could do up an ash grey t-shirt with slightly modified graphics. What would a "no -pthread" symbol look like? -- Brad Knowles, <[EMAIL PROTECTED]> "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, Historical Review of Pennsylvania. GCS/IT d+(-) s:+(++)>: a C++(+++)$ UMBSHI$ P+>++ L+ !E-(---) W+++(--) N+ !w--- O- M++ V PS++(+++) PE- Y+(++) PGP>+++ t+(+++) 5++(+++) X++(+++) R+(+++) tv+(+++) b+() DI+() D+(++) G+() e++> h--- r---(+++)* z(+++) ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: The bikeshed T-shirt
At 1:05 AM +0200 2003/09/12, Poul-Henning Kamp wrote: I don't want to get into the clothing business, so if you want one, you'll probably have to make it yourself. I can ask the company which produced them if they will be willing to ship abroad, but I doubt they are set up for that sort of thing. Per request, I have updated my version of the "FreeBSD No Bikeshed" t-shirt at <http://www.cafeshops.com/cp/prod.aspx?p=cmvp.6951805>. I removed the "BSDCon'03" text at the bottom and replaced it with "No Bikeshed". The slightly modified graphics I created for this shirt are available at <http://www.shub-internet.org/brad/pictures/FreeBSD-No-Bikeshed-R.png> and <http://www.shub-internet.org/brad/pictures/FreeBSD-No-Bikeshed-L.png>, under the same "No Bikeshed" license under which PHK released the original versions. -- Brad Knowles, <[EMAIL PROTECTED]> "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, Historical Review of Pennsylvania. GCS/IT d+(-) s:+(++)>: a C++(+++)$ UMBSHI$ P+>++ L+ !E-(---) W+++(--) N+ !w--- O- M++ V PS++(+++) PE- Y+(++) PGP>+++ t+(+++) 5++(+++) X++(+++) R+(+++) tv+(+++) b+() DI+() D+(++) G+() e++> h--- r---(+++)* z(+++) ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: panic: absolutely cannot call smp_ipi_shootdown with interrupts already disabled
At 4:47 PM -0700 2003/09/17, Doug White wrote: This came up at the developer summit. We do need to upgrade/make significant changes to gdb for it to understand threaded debugging. The panics might be interesting as it might be tickling other issues, but before we can really debug threaded apps we need a new gdb. Do we need a rewritten gdb, or can we have both the current gdb and a new tgdb for debugging the threaded stuff? The latter approach seems to be something that would be a lot easier to integrate without risk of breaking anything currently existing, and tgdb could even be done as a port until such time as it's fully ready to take over from the built-in gdb in the system. -- Brad Knowles, <[EMAIL PROTECTED]> "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, Historical Review of Pennsylvania. GCS/IT d+(-) s:+(++)>: a C++(+++)$ UMBSHI$ P+>++ L+ !E-(---) W+++(--) N+ !w--- O- M++ V PS++(+++) PE- Y+(++) PGP>+++ t+(+++) 5++(+++) X++(+++) R+(+++) tv+(+++) b+() DI+() D+(++) G+() e++> h--- r---(+++)* z(+++) ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: The bikeshed T-shirt
At 5:02 AM +0200 2003/09/12, Poul-Henning Kamp wrote: You misunderstood: "Yes, it is absolutely OK for you do print T-shirts, mugs, or anything else you might want to use it on." Sorry for the confusion. My version is now back at <http://www.cafeshops.com/cp/prod.aspx?p=cmvp.6951805>. -- Brad Knowles, <[EMAIL PROTECTED]> "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, Historical Review of Pennsylvania. GCS/IT d+(-) s:+(++)>: a C++(+++)$ UMBSHI$ P+>++ L+ !E-(---) W+++(--) N+ !w--- O- M++ V PS++(+++) PE- Y+(++) PGP>+++ t+(+++) 5++(+++) X++(+++) R+(+++) tv+(+++) b+() DI+() D+(++) G+() e++> h--- r---(+++)* z(+++) ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: bikeshed
At 5:10 AM +0200 2003/09/12, Poul-Henning Kamp wrote: You can use the "no bikeshed logo" for anything you want, anywhere you want, anytime you want with the following simple exception: Okay, the t-shirt is back, although now it's white instead of ash grey. See <http://www.cafeshops.com/cp/prod.aspx?p=cmvp.6951805>. YOU MAY NOT UNDER ANY CIRCUMSTANCES _EVER_ make it the subject of a bikeshed discussion. What about the color of the bikeshed? Can we make that an allowed bikeshed discussion? ;-) -- Brad Knowles, <[EMAIL PROTECTED]> "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, Historical Review of Pennsylvania. GCS/IT d+(-) s:+(++)>: a C++(+++)$ UMBSHI$ P+>++ L+ !E-(---) W+++(--) N+ !w--- O- M++ V PS++(+++) PE- Y+(++) PGP>+++ t+(+++) 5++(+++) X++(+++) R+(+++) tv+(+++) b+() DI+() D+(++) G+() e++> h--- r---(+++)* z(+++) ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: The bikeshed T-shirt
At 5:02 AM +0200 2003/09/12, Poul-Henning Kamp wrote: Yes, absolutely. Okay, it should be down in a few minutes. You misunderstood: "Yes, it is absolutely OK for you do print T-shirts, mugs, or anything else you might want to use it on." Sorry about that. Originally I wasn't sure, but on thinking about it some more, I felt more confident that you had meant something else. I guess I over-analyzed your response. I'll put the shirt back up in a few minutes. -- Brad Knowles, <[EMAIL PROTECTED]> "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, Historical Review of Pennsylvania. GCS/IT d+(-) s:+(++)>: a C++(+++)$ UMBSHI$ P+>++ L+ !E-(---) W+++(--) N+ !w--- O- M++ V PS++(+++) PE- Y+(++) PGP>+++ t+(+++) 5++(+++) X++(+++) R+(+++) tv+(+++) b+() DI+() D+(++) G+() e++> h--- r---(+++)* z(+++) ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: The bikeshed T-shirt
At 10:17 PM -0300 2003/09/11, Daniel C. Sobral wrote: Yes. Maybe we should remove Brad's commit bit until he puts the t-shirt up again??? :-) I concede that I may have mis-interpreted PHK's response, but before I consider putting the shirt design back up, I need to get explicit confirmation from him that this is okay. I thought about whether or not this was a mis-interpretation or not, but he's usually pretty careful about trimming the quote to which he is responding. I would have expected him to omit the last sentence of that paragraph if his response was positive, but since he kept it, I concluded that he was against the idea. The images should probably have a copyright statement attached to them, and specify under what kind of license they may be distributed under. I can add that to the PNGs I generated (at PHK's direction), or he can re-generate the source files from which I will work. -- Brad Knowles, <[EMAIL PROTECTED]> "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, Historical Review of Pennsylvania. GCS/IT d+(-) s:+(++)>: a C++(+++)$ UMBSHI$ P+>++ L+ !E-(---) W+++(--) N+ !w--- O- M++ V PS++(+++) PE- Y+(++) PGP>+++ t+(+++) 5++(+++) X++(+++) R+(+++) tv+(+++) b+() DI+() D+(++) G+() e++> h--- r---(+++)* z(+++) ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: The bikeshed T-shirt
At 2:00 AM +0200 2003/09/12, Brad Knowles wrote: Problem solved. See <http://www.cafeshops.com/cmvp.7534915>. Note that these are being sold at cost (something any other CafePress member can confirm). Per PHK's request, I am taking this down. The PNG version I created is at <http://www.shub-internet.org/brad/pictures/freebsd-bikeshed.png>. I will leave my PNG version of the bikeshed graphic in place, unless I get another request from PHK to remove it. -- Brad Knowles, <[EMAIL PROTECTED]> "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, Historical Review of Pennsylvania. GCS/IT d+(-) s:+(++)>: a C++(+++)$ UMBSHI$ P+>++ L+ !E-(---) W+++(--) N+ !w--- O- M++ V PS++(+++) PE- Y+(++) PGP>+++ t+(+++) 5++(+++) X++(+++) R+(+++) tv+(+++) b+() DI+() D+(++) G+() e++> h--- r---(+++)* z(+++) ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: The bikeshed T-shirt
At 2:11 AM +0200 2003/09/12, Poul-Henning Kamp wrote: Yes, absolutely. Okay, it should be down in a few minutes. If you are serious about wanting to make the image available to others for use on t-shirts, I would encourage you to set up your own CafePress shop, as one of the easiest ways to quickly take any image you want and put it on a wide variety of different products from t-shirts, hats, aprons, mugs, and a whole host of others. -- Brad Knowles, <[EMAIL PROTECTED]> "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, Historical Review of Pennsylvania. GCS/IT d+(-) s:+(++)>: a C++(+++)$ UMBSHI$ P+>++ L+ !E-(---) W+++(--) N+ !w--- O- M++ V PS++(+++) PE- Y+(++) PGP>+++ t+(+++) 5++(+++) X++(+++) R+(+++) tv+(+++) b+() DI+() D+(++) G+() e++> h--- r---(+++)* z(+++) ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: The bikeshed T-shirt
At 1:05 AM +0200 2003/09/12, Poul-Henning Kamp wrote: I don't want to get into the clothing business, so if you want one, you'll probably have to make it yourself. I can ask the company which produced them if they will be willing to ship abroad, but I doubt they are set up for that sort of thing. Problem solved. See <http://www.cafeshops.com/cmvp.7534915>. Note that these are being sold at cost (something any other CafePress member can confirm). The xfig source is here: http://phk.frebsd.dk/misc/bsdcon03.fig http://phk.frebsd.dk/misc/bsdcon03.pdf The PNG version I created is at <http://www.shub-internet.org/brad/pictures/freebsd-bikeshed.png>. Enjoy... I have interpreted your post to mean that it's okay for other people to print up t-shirts, based on this image. However, if you prefer that I take this down, just let me know. -- Brad Knowles, <[EMAIL PROTECTED]> "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, Historical Review of Pennsylvania. GCS/IT d+(-) s:+(++)>: a C++(+++)$ UMBSHI$ P+>++ L+ !E-(---) W+++(--) N+ !w--- O- M++ V PS++(+++) PE- Y+(++) PGP>+++ t+(+++) 5++(+++) X++(+++) R+(+++) tv+(+++) b+() DI+() D+(++) G+() e++> h--- r---(+++)* z(+++) ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: System freezes with radeon 9100 graphics card
At 9:40 PM -0700 2003/08/23, Scott M. Likens wrote: Also please teach your email client to word wrap. That's nasty. According to your headers, you're using Ximian Evolution 1.4.4. According to his headers, he's running Mutt/1.5.4i. You tell me. -- Brad Knowles, <[EMAIL PROTECTED]> "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, Historical Review of Pennsylvania. GCS/IT d+(-) s:+(++)>: a C++(+++)$ UMBSHI$ P+>++ L+ !E-(---) W+++(--) N+ !w--- O- M++ V PS++(+++) PE- Y+(++) PGP>+++ t+(+++) 5++(+++) X++(+++) R+(+++) tv+(+++) b+() DI+() D+(++) G+() e++> h--- r---(+++)* z(+++) ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: INET6 in world
At 12:16 PM -0700 2003/08/05, Kevin Oberman wrote: I may have missed part of this tread as I am on travel. Why is simply not enabling ipv6 adequate? Note: I DO run IPv6 routinely when at work, so I normally do have it enabled. I'd like to get an understanding of what the issue might be. The point is clearly strongly heald be some reasonably knowledgeable people. I'm from the school where you don't run anything you don't absolutely need. Not even if the code is not being used, just loaded. I don't mind having the code on disk and accessible if/when I need it (even though that's also a risk), but I absolutely do not want the code loaded unless I'm actually going to be making use of it. -- Brad Knowles, <[EMAIL PROTECTED]> "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, Historical Review of Pennsylvania. GCS/IT d+(-) s:+(++)>: a C++(+++)$ UMBSHI$ P+>++ L+ !E-(---) W+++(--) N+ !w--- O- M++ V PS++(+++) PE- Y+(++) PGP>+++ t+(+++) 5++(+++) X++(+++) R+(+++) tv+(+++) b+() DI+() D+(++) G+() e++> h--- r---(+++)* z(+++) ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: INET6 in world
At 9:37 AM -0700 2003/08/05, David O'Brien wrote: Machanism, not policy. I would also like to run with NO_INET6. IPv6 support has done nothing for me other than cause me problems. I still strongly disagree with our ordering of localhost in /etc/hosts. My system worked worlds better when I put the IPv4 localhost first. There is no IPv6 in this house, nor is there likely to be any time soon. If I can't kill IPv6 from a configuration standpoint, I'll go ripping out the freakin' code, or I'll use an OS that gives me the option. -- Brad Knowles, <[EMAIL PROTECTED]> "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, Historical Review of Pennsylvania. GCS/IT d+(-) s:+(++)>: a C++(+++)$ UMBSHI$ P+>++ L+ !E-(---) W+++(--) N+ !w--- O- M++ V PS++(+++) PE- Y+(++) PGP>+++ t+(+++) 5++(+++) X++(+++) R+(+++) tv+(+++) b+() DI+() D+(++) G+() e++> h--- r---(+++)* z(+++) ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Any patch for ICMP in a jail?
At 8:35 AM -0400 2003/08/04, Robert Watson wrote: The best short-term suggestion would be to write a privilege-separated ping tool -- a pingd running outside the jail, providing UNIX domain sockets in each jail that needs the ability to ping; ping then becomes a client that RPC's to pingd. It strikes me that this is probably a better solution to the problem regardless of whether or not you are in a jail. By carefully controlling the RPC interface, you should be able to reduce the security exposure, simplify pingd, and bring more of the complex logic into the unprivileged ping client. This would also allow you to apply the same solution for jail vs. non-jail environments. Is this a future enhancement that we can realistically look forward to? -- Brad Knowles, <[EMAIL PROTECTED]> "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, Historical Review of Pennsylvania. GCS/IT d+(-) s:+(++)>: a C++(+++)$ UMBSHI$ P+>++ L+ !E-(---) W+++(--) N+ !w--- O- M++ V PS++(+++) PE- Y+(++) PGP>+++ t+(+++) 5++(+++) X++(+++) R+(+++) tv+(+++) b+() DI+() D+(++) G+() e++> h--- r---(+++)* z(+++) ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Lucent IBSS mode doesn't work in -CURRENT?
At 11:51 PM -0600 2003/08/03, M. Warner Losh wrote: In message: <[EMAIL PROTECTED]> "Greg 'groggy' Lehey" <[EMAIL PROTECTED]> writes: : On Thursday, 31 July 2003 at 9:30:31 +0200, Eirik Oeverby wrote: : > : > Oh and btw.. Get the *latest* firmware onto all your cards. That is : > essential for anything to work right at all.. : : That sounds wrong to me. If it worked before, and it doesn't now, : that's not the fault of the firmware. Quit harping on it, ok. We know there's a bug and carping like this makes me less willing to find and fix it. I'm confused. I agree that I have sometimes found Greg to be a bit annoying, but it seems to me that he's asking a perfectly legitimate question -- if things worked fine in the past (including the firmware versions at the time), and they don't work now, then why is a firmware update needed? I would ask: What changed so that things broke, and why can't we go back to the way things worked before? Please, this is a serious question. I'm not running 5.x yet on my in-house server/laptop, but I hope to soon (once I get some more servers in the house on which I can be more conservative), and a Lucent WaveLAN gold is definitely one of the things I plan on sticking in there to play with. I really want this to work, and I don't understand how we got to the situation we're in today. Can you explain things to me, perhaps in a somewhat simpler fashion, so that I might understand, and maybe even help? -- Brad Knowles, <[EMAIL PROTECTED]> "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, Historical Review of Pennsylvania. GCS/IT d+(-) s:+(++)>: a C++(+++)$ UMBSHI$ P+>++ L+ !E-(---) W+++(--) N+ !w--- O- M++ V PS++(+++) PE- Y+(++) PGP>+++ t+(+++) 5++(+++) X++(+++) R+(+++) tv+(+++) b+() DI+() D+(++) G+() e++> h--- r---(+++)* z(+++) ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Belkin F5D5020 PCMCIA Card/Notebook Network Card
At 2:38 AM -0500 2003/07/28, Nick H. - Network Operations wrote: Does support for the Belkin F5D5020 PCMCIA Card/Notebook Network Card exist in FreeBSD 5.0-RELEASE? According to Belkin, it does, but I have been unable to find any support for this card. Any suggestions on the right place to look are more than welcome. Back in October of last year, I cooked up a pccard.conf entry for it that seemed to mostly work: # Belkin F5D5020 NE2000-compatible card (FCC ID: LXLC1LANTB) card "Belkin" "F5D5020-PCMCIA-Network-Card" config auto "ed" ? logstr "Belkin F5D5020 10/100 Base-TX Ethernet 16-bit PCMCIA card (NE2000-compatible)" insert /etc/pccard_ether $device start remove /etc/pccard_ether $device stop I submitted this to Warner Losh, but IIRC, I got an indication back that this wasn't right. However, I don't recall that I ever got any correct pccard.conf setting for this device, and while I could get FreeBSD to see the card and use this entry to mostly recognize it, I could not actually get any positive network results this way. Any additional information you can find would be appreciated. Right now, I'm using a Linksys (EtherFast 10/100 Integrated PC Card (PCM100) on the machine where I was trying to use the Belkin, but it sticks out from the machine and blocks the second PC Card slot, so I'd prefer to use the Belkin (which is flush with the edge and comes with a dongle), if possible. If I could get them both working, or get one of them working with one of my various 802.11b WiFi cards, then I would have two NICs and could do some much more interesting things with this machine. Unfortunately, everything seems to want IRQ3, so even if I could get the individual cards working by themselves, I don't know if I could ever get them working together. I did find an interesting entry at <http://www.freebsdforums.org/forums/showthread.php?threadid=8315>, at the bottom (dated April 2002) that shows the pccard.conf entry of: # Belkin F5D5020 card "Belkin" "F5D5020-PCMCIA-Network-Card" config auto "ed" ? 0x10 insert /etc/pccard_ether $device start remove /etc/pccard_ether $device stop Which the author claims (claimed) works (worked) for him. You can see my posts from October of last year at <http://docs.freebsd.org/cgi/getmsg.cgi?fetch=753513+0+archive/2002/freebsd-questions/20021013.freebsd-questions>, <http://docs.freebsd.org/cgi/getmsg.cgi?fetch=2755078+0+archive/2002/freebsd-questions/20021013.freebsd-questions>, and <http://docs.freebsd.org/cgi/getmsg.cgi?fetch=750581+0+archive/2002/freebsd-questions/20021013.freebsd-questions>. And then there's the post at <http://lists.freebsd.org/pipermail/freebsd-questions/2003-April/001987.html> from April, which also mentions this card. But still, no answers to this question. Unfortunately, just Googling for "Belkin F5D5020 FreeBSD" doesn't do much good, as it turns up many resellers of this card which claims that it works with FreeBSD, or articles that happen to mention both FreeBSD and this card on the same page (such as <http://www.23degrees.net/mt/archives/000135.html>), but which don't actually provide any solutions. -- Brad Knowles, <[EMAIL PROTECTED]> "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, Historical Review of Pennsylvania. GCS/IT d+(-) s:+(++)>: a C++(+++)$ UMBSHI$ P+>++ L+ !E-(---) W+++(--) N+ !w--- O- M++ V PS++(+++) PE- Y+(++) PGP>+++ t+(+++) 5++(+++) X++(+++) R+(+++) tv+(+++) b+() DI+() D+(++) G+() e++> h--- r---(+++)* z(+++) ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
We have ath, now what about Broadcom?
Folks, Okay, so now I just figured out what the "ath" driver is. Sigh... Of course, I find this out through searching for open source drivers for the Broadcom chipset as used in the Linksys WPC54G cardbus device, which I happen to have just bought. I've already done quite a bit of Googling and searching through the archives, and I haven't found anything obviously relevant to the issue of drivers for the Broadcom chipset, at least not anything recent. I did find a lot of old references to drivers for this chipset in the April timeframe, mostly having to do with people discovering that Linksys was shipping access points & routers using this chipset, using Linux for MIPS and BusyBox, but not providing the drivers themselves under their GPL obligations. Can anyone provide some pointers or links that would bring me up-to-date on the current state of affairs on this subject, especially as it related to FreeBSD or *BSD in general? Thanks! -- Brad Knowles, <[EMAIL PROTECTED]> "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, Historical Review of Pennsylvania. GCS/IT d+(-) s:+(++)>: a C++(+++)$ UMBSHI$ P+>++ L+ !E-(---) W+++(--) N+ !w--- O- M++ V PS++(+++) PE- Y+(++) PGP>+++ t+(+++) 5++(+++) X++(+++) R+(+++) tv+(+++) b+() DI+() D+(++) G+() e++> h--- r---(+++)* z(+++) ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ReiserFS
At 9:50 AM -0700 2003/06/22, Lars Eggert wrote: Make the ReiserFS box an NFS server and mount it on FreeBSD to copy the data over. What if it's the same machine? What if they have only the one machine, so they can't even copy it over to another one, just to copy it back? -- Brad Knowles, <[EMAIL PROTECTED]> "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, Historical Review of Pennsylvania. GCS/IT d+(-) s:+(++)>: a C++(+++)$ UMBSHI$ P+>++ L+ !E-(---) W+++(--) N+ !w--- O- M++ V PS++(+++) PE- Y+(++) PGP>+++ t+(+++) 5++(+++) X++(+++) R+(+++) tv+(+++) b+() DI+() D+(++) G+() e++> h--- r---(+++)* z(+++) ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Way forward with BIND 8
At 6:02 PM -0700 2003/06/06, Doug Barton wrote: You've failed to grasp the distinction I made between "adventursome bits in contrib" vs. "adventursome bits in the rest of src/." Also, SMPng is a really good example of my point... it's a major API change IN FREEBSD CODE that definitely belongs in HEAD, for eventual -stable'ification of that branch. If we decide to do the same thing with BIND, it should be in the next major development branch. There is already enough excitement in what will be RELENG_5. IMO, that's okay. However, I find this to be a rather different statement than you made on the website, and that you have previously stated within this thread. If you care to update the website to reflect this new position, I would be happy to let this thread drop. See my other message for more. A) My level of involvement in BIND development is none of your business. B) My level of involvement in BIND development is not even a little bit related to whether bind 9 is suitable to import into FreeBSD yet. You've confused the thing we're trying to prove, "Is bind 9 ready for freebsd?" with a premise in your own absurd logic, "Because bind 9 is the best thing ever, dougb should fix it so he can put it in freebsd." You're the maintainer of the BIND code within FreeBSD. You should be feeding changes back to the ISC based on your work, to make FreeBSD a better home for BIND and BIND a better client for FreeBSD. If you're not doing that, then, IMO, you're not doing your job. In that case, perhaps it would be better if we got someone from the ISC to take over, in somewhat the same way that we have Gregory Neil Shapiro supporting sendmail within FreeBSD. You've also completely ignored the part of my post where I pointed out that everyone who wants what you're advocating (no bind 8 in the base, and/or having bind 9 in the base) can have it, right now, no waiting. The fact that it requires to extra, extremely painless configuration steps is, arguably, unfortunate, however I don't think it's too much to ask, at least in the near term. For me, this subject has nothing to do with what people are capable of doing, if they so choose. At issue is what is the default software installed out-of-the-box. As I said above, if you want to hold off on importing BIND 9 until after the looming CURRENT/STABLE transition, I have no problems with that. However, I would like to see you update the web page you previously mentioned. -- Brad Knowles, <[EMAIL PROTECTED]> "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, Historical Review of Pennsylvania. GCS/IT d+(-) s:+(++)>: a C++(+++)$ UMBSHI$ P+>++ L+ !E-(---) W+++(--) N+ !w--- O- M++ V PS++(+++) PE- Y+(++) PGP>+++ t+(+++) 5++(+++) X++(+++) R+(+++) tv+(+++) b+() DI+() D+(++) G+() e++> h--- r---(+++)* z(+++) ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Way forward with BIND 8
At 5:31 PM -0700 2003/06/06, Doug Barton wrote: On Fri, 6 Jun 2003, Paul Robinson wrote: let me just ask for clarification on something. Are you stating as the BIND maintainer around these parts that FreeBSD will never have BIND 9? No, that's not what I'm saying at all. Someone else already pointed out that I said "at this time" above. I plan to look at this issue again for 6-current, but right now, it's not a suitable choice, in my opinion. This is a rather different statement than you previously gave. I understand the current state of 5.x, and if you want to hold off on importing BIND 9 into the tree until after this has become the new -STABLE branch and a new -CURRENT branch has been created for 6.x, I don't have a problem with that. But this is not at all how I interpreted your previous statements -- they were much more of an absolute "It's not ready" nature, and had nothing to do with the situation that FreeBSD finds itself in at the moment with regards to the 5.x tree. This is not accurate. There are some things that named in bind 8 can do that named in bind 9 won't (and won't ever). There is also the fact that output from dig and host are different, which can cause problems with scripts. Yes, there are differences in the output of dig, etc Those are known. I've had to adapt scripts that I maintain which use these tools, and which are included in the BIND contrib/ directory. This is a done deal, and with respect to the ISC version of BIND, it's not going to change -- they've made the cutover, these changes have happened, people have adjusted their code, and it would be too painful to change it all back again. Unless you want to permanently fork off your own version of BIND where none of these things happen, you're just plain out of luck. For these reasons alone, we can't even consider MFC'ing bind 9 to RELENG_4, it's too big of a POLA violation. I did not ask for that. I would not have asked for that. I do want to see BIND 9 brought into the FreeBSD code base for -CURRENT. If now is not the right time to do that because of the transition underway, then I would not mind a relatively short delay while the FreeBSD project makes the necessary changes so that it can import BIND 9. However, IMO these issues have more to do with the status of -CURRENT at the moment than it does with BIND 9. Development is continuing on BIND 8 as well, thus the 8.4.x branch, which includes IPv6 transport. Very limited development. All primary development is being done for BIND 9, and occasionally things are back-ported. -- Brad Knowles, <[EMAIL PROTECTED]> "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, Historical Review of Pennsylvania. GCS/IT d+(-) s:+(++)>: a C++(+++)$ UMBSHI$ P+>++ L+ !E-(---) W+++(--) N+ !w--- O- M++ V PS++(+++) PE- Y+(++) PGP>+++ t+(+++) 5++(+++) X++(+++) R+(+++) tv+(+++) b+() DI+() D+(++) G+() e++> h--- r---(+++)* z(+++) ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Way forward with BIND 8
At 3:01 AM -0700 2003/06/06, Doug Barton wrote: Regardless of whether I agree with the points you make here or not, the FreeBSD development model requires that what we import in -current, for the most part, be what we plan to eventually MFC. That factor alone eliminates the possibility of importing BIND 9 at this time. I'm sorry, plenty of things have been done in -CURRENT that could not possibly be MFC'ed to -STABLE. Yes, once the leap to the next version is done and the particular RELENG tree that used to be -CURRENT becomes the new -STABLE, things would migrate down. Are you saying that the new SMP code could not have been done, because it could not be MFC'ed to -STABLE? I'm sorry, this is a completely false argument. There's no sense re-hashing all these issues in e-mail and yet you felt the need to do so. No, I didn't. If I had, I would have cut-n-pasted all those specific points into my e-mail message. As it was, I mentioned one or two points on either side, and referred people to the rest. Nothing I've had to say on this issue should be (or I think reasonably can be) interpreted as a flame. I've simply stated the reasons I think that BIND 9 isn't suitable for one particular purpose. In which case, I would submit that you should be more involved in the development of BIND, so that (in your mind) it can become suitable for this purpose. Are you a member of the BIND Forum (see <http://www.isc.org/BINDForum/>)? Are you on the bind-workers mailing list? IMO, if you want to claim that BIND 9 isn't suitable for production use, then I believe you should be prepared to help change that situation. -- Brad Knowles, <[EMAIL PROTECTED]> "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, Historical Review of Pennsylvania. GCS/IT d+(-) s:+(++)>: a C++(+++)$ UMBSHI$ P+>++ L+ !E-(---) W+++(--) N+ !w--- O- M++ V PS++(+++) PE- Y+(++) PGP>+++ t+(+++) 5++(+++) X++(+++) R+(+++) tv+(+++) b+() DI+() D+(++) G+() e++> h--- r---(+++)* z(+++) ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Way forward with BIND 8
At 12:09 AM -0700 2003/06/06, Doug Barton wrote: FYI, for those wondering why I'm not considering BIND 9 for import, please see http://people.freebsd.org/~dougb/whybind8.html I might be able to buy your arguments for supporting BIND 8 instead of BIND 9 in -STABLE, but not in -CURRENT. BIND 9 is the future. BIND 8 is ancient spaghetti code that only kinda-semi-sorta holds together, and there is only one guy working on maintaining it during the turn-down phase to EOL. BIND 9 uses new secure programming techniques that cause it to apply near-paranoid checks to data inputs and intentionally crash if it finds anything amiss. This helps ensure that almost all major input bugs are found and fixed before the code ever leaves the ISC. There's no sense re-hashing all these issues in e-mail -- I've got a whole host of reasons why BIND 8 is bad, and why BIND 9 is better. See slides 66-72 of my talk _Domain Name Server Comparison: BIND 8 vs. BIND 9 vs. djbdns vs. ???_, as presented at RIPE 44 in Amsterdam (at <http://www.shub-internet.org/brad/papers/dnscomparison/DNSComp-RIPE44.pdf.gz>). Also note that if you're going to flame someone for development on BIND 9, you shouldn't be flaming Nominum. They no longer do any work on BIND 9, and some of the people who were doing that work have been transferred to work directly for the ISC (as opposed to doing the work as Nominum employees under contract to the ISC). Indeed, even when Nominum was doing development on BIND 9 under contract to the ISC, the ISC still controlled the direction of the development and the overall manner in which the code would be written, with Nominum handling the implementation details. Therefore, even if you had these complaints years ago, you should still have addressed them to the ISC, not Nominum. Anyway, the argument for having separate -STABLE and -CURRENT branches is so that development on new code can progress, and adventurous types can give the new stuff a try (and help debug it), while less adventurous types can stick with tried-n-true. If you believe this argument at all, you cannot possibly justify keeping BIND 8 in -CURRENT. Virtually everything negative you have to say about BIND 9 is something that could also be said of -CURRENT. How do you expect that we can ever arrive at a -STABLE without first having a -CURRENT? Well, the same is true for BIND 9. Indeed, I'd say that BIND 9 is much more mature and production-ready than -CURRENT is most of the time (situations such as the current transition where we're just about to make 5.x the new -STABLE being the one exception I can think of). -- Brad Knowles, <[EMAIL PROTECTED]> "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, Historical Review of Pennsylvania. GCS/IT d+(-) s:+(++)>: a C++(+++)$ UMBSHI$ P+>++ L+ !E-(---) W+++(--) N+ !w--- O- M++ V PS++(+++) PE- Y+(++) PGP>+++ t+(+++) 5++(+++) X++(+++) R+(+++) tv+(+++) b+() DI+() D+(++) G+() e++> h--- r---(+++)* z(+++) ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: HEADS UP: bzip2(1) compression for manpages, Groffand Texinfo docs
At 7:43 PM +0200 2003/05/02, Matthias Buelow wrote: The two programs, however, only do the same thing if you consider that they're both compressors. bzip2 eats much more resources than gzip, both space and time. And the algorithm is rather overkill for small files anyways. Granted, the space savings is not that much. I took /usr/share/man/man1 from a 4.6.2-RELEASE box and made three copies of it under /tmp/man, uncompressed all the files, and then re-compressed them using `compress`, `gzip -9`, and `bzip2`. Here's the results: % du * | sort -nr 4646compress 3624gzip 3422bzip2 So, bzip2 is not that much of an improvement over gzip (~6%), but it is a fair improvement over compress (~35.7%). This is just one section of the man pages, and does not include the cat pages, but I figure it's probably fairly representative. I haven't looked at the stuff under /usr/share/info or /usr/share/doc. I'm not sure which of those files would be compressed and which ones wouldn't. These three directories comprise ~82MB of disk space, of which about 15MB is in /usr/share/man and about 64.6MB in /usr/share/doc. At the moment, it doesn't appear that the files in /usr/share/doc are compressed at all, so there might be significant storage savings there. I built a tarball from the /usr/share/doc hierarchy, and tried the three different compression programs on it. I know that compression on a tarball is going to be different from compression on individual files, but this should at least give us some idea. Anyway, here's the results: % ls -1s doc* | sort -nr 64368 doc.tar 22896 doc-compress.tar.Z 16080 doc-gzip.tar.gz 12032 doc-bzip2.tar.bz2 So, bzip2 result in a file about 18.6% of the size of the original, gzip does about 24.9%, and compress is only 35.5%. Relatively speaking, bzip2 results in a file that is about 74.8% the size of the version produced by `gzip -9`. Seeing as /usr/share/doc and /usr/share/info is not currently compressed (in 4.6.2-RELEASE), any compression algorithm would be a significant improvement. -- Brad Knowles, <[EMAIL PROTECTED]> "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, Historical Review of Pennsylvania. GCS/IT d+(-) s:+(++)>: a C++(+++)$ UMBSHI$ P+>++ L+ !E-(---) W+++(--) N+ !w--- O- M++ V PS++(+++) PE- Y+(++) PGP>+++ t+(+++) 5++(+++) X++(+++) R+(+++) tv+(+++) b+() DI+() D+(++) G+() e++> h--- r---(+++)* z(+++) ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Anyone working on fsck?
At 2:42 PM -0800 2003/03/18, Terry Lambert wrote: Make sense now? No. However, I am now convinced that I don't understand enough of how the filesystem works to even be able to ask the simplest of questions about how this process can be improved. So, I will now shut up. -- Brad Knowles, <[EMAIL PROTECTED]> "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, Historical Review of Pennsylvania. GCS/IT d+(-) s:+(++)>: a C++(+++)$ UMBSHI$ P+>++ L+ !E-(---) W+++(--) N+ !w--- O- M++ V PS++(+++) PE- Y+(++) PGP>+++ t+(+++) 5++(+++) X++(+++) R+(+++) tv+(+++) b+() DI+() D+(++) G+() e++> h--- r---(+++)* z(+++) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Anyone working on fsck?
At 7:17 AM +0100 2003/03/18, Poul-Henning Kamp wrote: Optimizing fsck is a valid project, I just wish it would be somebody who would also finish the last 30% who would do it. Just what are you saying? Is Julian Elischer not the right person to be working on this, because he has a history of not finishing the last 30% of something? Yes. Can you substantiate this rather extreme claim? Can you point to specific messages in the archives that demonstrate this? -- Brad Knowles, <[EMAIL PROTECTED]> "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, Historical Review of Pennsylvania. GCS/IT d+(-) s:+(++)>: a C++(+++)$ UMBSHI$ P+>++ L+ !E-(---) W+++(--) N+ !w--- O- M++ V PS++(+++) PE- Y+(++) PGP>+++ t+(+++) 5++(+++) X++(+++) R+(+++) tv+(+++) b+() DI+() D+(++) G+() e++> h--- r---(+++)* z(+++) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Anyone working on fsck?
At 10:49 PM -0800 2003/03/17, Terry Lambert wrote: Yes, I know. I'm aware. He has a lot of data to transfer in from the disk in order to do the reverse lookup, with that much data on the disk. I'm confused. In situations where you need to do reverse lookups, don't you normally tend to create doubly-linked lists, or other structures that you can traverse quickly and efficiently? He could change the code so that that everything that wasn't in use was zeroed. That would help, since then he could just create a second CG map in an empty file by traversing all inodes and indirect blocks for non-zero values, not caring if the indirect blocks were referenced by inodes. Assuming indirect blocks and data blocks were distinguishable. Like I said, there are a lot of FS changes that could help. I'm not sure I understand how this would be a filesystem change. Since this second CG map would be used only during fsck and not otherwise present on the system, couldn't you just throw it away when you were done, resulting in a filesystem that was structurally unchanged from before? The *reason* it doesn't matter in the CG bitmap case, is that a bitmap can only tell "allocated" vs. "unallocated"; there is no third state that means "I haven't checked this bit yet". So you can only load up however many bitmaps you are going to check in a given pass (hopefully they all fit in memory, but if they don't fitting in the address space does you no good, because they still aren't tri-state), and then iterate every single bit reference in existance, and compare them to the ones you have, and clear them if they aren't referenced by *anyone*. Seems to me that you could easily solve this with a second CG map (as you proposed above), that starts of initially zeroed for all blocks, and as you go through the "normal" CG maps, you turn on all the corresponding bits in the corresponding second map as you touch the blocks that are referenced. This should be a single linear pass, and then you'd be done. If you had one I/O process and multiple worker processes actually scanning the CG maps and updating the second copy, this should just absolutely *fly*. What am I missing here? -- Brad Knowles, <[EMAIL PROTECTED]> "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, Historical Review of Pennsylvania. GCS/IT d+(-) s:+(++)>: a C++(+++)$ UMBSHI$ P+>++ L+ !E-(---) W+++(--) N+ !w--- O- M++ V PS++(+++) PE- Y+(++) PGP>+++ t+(+++) 5++(+++) X++(+++) R+(+++) tv+(+++) b+() DI+() D+(++) G+() e++> h--- r---(+++)* z(+++) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Anyone working on fsck?
At 8:32 PM -0800 2003/03/17, Terry Lambert wrote: Even so, for RAID, this is generally problematic, because there's multiple locations for the block: where it lives, where it's mirrored, where it's parity block lives, etc.. Ideally, these are all different spindles, so the problem can't be fixed by a simple cache. 8-(. It seems to me that there could be a logical cache which could be provided by the RAID code, which would sit above the physical block locations, the mirrors of the blocks, the parity data, etc Or is this the part that is provided by the filesystem? -- Brad Knowles, <[EMAIL PROTECTED]> "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, Historical Review of Pennsylvania. GCS/IT d+(-) s:+(++)>: a C++(+++)$ UMBSHI$ P+>++ L+ !E-(---) W+++(--) N+ !w--- O- M++ V PS++(+++) PE- Y+(++) PGP>+++ t+(+++) 5++(+++) X++(+++) R+(+++) tv+(+++) b+() DI+() D+(++) G+() e++> h--- r---(+++)* z(+++) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Anyone working on fsck?
At 10:39 PM +0100 2003/03/17, Poul-Henning Kamp wrote: Optimizing fsck is a valid project, I just wish it would be somebody who would also finish the last 30% who would do it. Just what are you saying? Is Julian Elischer not the right person to be working on this, because he has a history of not finishing the last 30% of something? -- Brad Knowles, <[EMAIL PROTECTED]> "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, Historical Review of Pennsylvania. GCS/IT d+(-) s:+(++)>: a C++(+++)$ UMBSHI$ P+>++ L+ !E-(---) W+++(--) N+ !w--- O- M++ V PS++(+++) PE- Y+(++) PGP>+++ t+(+++) 5++(+++) X++(+++) R+(+++) tv+(+++) b+() DI+() D+(++) G+() e++> h--- r---(+++)* z(+++) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Plea for base system trim
At 2:07 AM +0100 2003/03/06, Philip Paeps wrote: Speaking of ndc, I think that's a BIND8-ism. Indeed, it is. With BIND-9, ndc won't even work -- Unix sockets aren't supported, and IP sockets are secured with crypto keys. Could the port be convinced to symlink it to rndc when set to replace the base, or would that confuse other things? Currently, I'm just aliasing it in my shell, but that seems a bit hackish :-) That could potentially be done, but keep in mind that there are some things that ndc can do that rndc can't -- "ndc start" being one of the big ones. -- Brad Knowles, <[EMAIL PROTECTED]> "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, Historical Review of Pennsylvania. GCS/IT d+(-) s:+(++)>: a C++(+++)$ UMBSHI$ P+>++ L+ !E-(---) W+++(--) N+ !w--- O- M++ V PS++(+++) PE- Y+(++) PGP>+++ t+(+++) 5++(+++) X++(+++) R+(+++) tv+(+++) b+() DI+() D+(++) G+() e++> h--- r---(+++)* z(+++) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: TI WiFi Drivers
At 7:27 PM + 2003/03/01, Suneel Jhangiani wrote: Does anyone know if someone is working on WiFi drivers for cards based on the TI chipset running at 22Mbps (ie. D-link DWL-650+ pcmcia card)? If you can get them, please let me know. A friend & co-worker (Bas Vermeulen) does driver development for Linux, currently specializing in WiFi cards. He has been able to get samples of the cards themselves, but can't get TI or any of their licensees to even talk to him about the specs or other sufficient information to allow him to write the driver. If we can get a driver under the BSD license, I'm sure that'd help him write a driver for Linux, and he would be a very happy camper. -- Brad Knowles, <[EMAIL PROTECTED]> "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, Historical Review of Pennsylvania. GCS/IT d+(-) s:+(++)>: a C++(+++)$ UMBSHI$ P+>++ L+ !E-(---) W+++(--) N+ !w--- O- M++ V PS++(+++) PE- Y+(++) PGP>+++ t+(+++) 5++(+++) X++(+++) R+(+++) tv+(+++) b+() DI+() D+(++) G+() e++> h--- r---(+++)* z(+++) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Any ideas why we can't even boot a i386 ?
At 9:38 PM -0500 2003/02/27, Garance A Drosihn wrote: It's never good to add to your release cycle something you don't build/validate during development. Releases are painful enough that you don't want to turn them into testbeds. If it's not worth testing during development, it's not worth releasing... Okay, that also makes good sense. But if that is true, then maybe we should officially tell our users that they *must* stay with the 4.x-series if they are running 386 hardware. I do think that the project has plenty of work with 5.x-series, particularly as we try to add sparc64, ppc, and maybe more hardware platforms. I disagree. We should tell them that 5.x may technically run on i386 systems, but that it is optimized for i486 and above, and that if they want to get it to run on i386 machines there is a significant amount of additional work that they would need to go through in order to make it happen. We can go so far as to tell them that using 5.x on i386 hardware is unsupported, and if they have any problems they shouldn't bother reporting them to us. However, I would encourage people to do further testing of 5.x on i386 systems and try to keep it working, and I would be very disappointed if anyone made any proclamations that people *MUST* stick with 4.x (or earlier) if they're using i386 systems. If you're going to go that route, then make sure to actually remove all the i386 code from 5.x so that it simply is no longer possible to make it work at all. Actually, this might be a good exercise anyway, to help teach us just what parts can be disentangled and what parts would need to be watched more closely. But don't tell people that they *MUST* stick with 4.x on i386, unless you physically remove all the i386 code from the 5.x tree. -- Brad Knowles, <[EMAIL PROTECTED]> "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, Historical Review of Pennsylvania. GCS/IT d+(-) s:+(++)>: a C++(+++)$ UMBSHI$ P+>++ L+ !E-(---) W+++(--) N+ !w--- O- M++ V PS++(+++) PE- Y+(++) PGP>+++ t+(+++) 5++(+++) X++(+++) R+(+++) tv+(+++) b+() DI+() D+(++) G+() e++> h--- r---(+++)* z(+++) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: WLAN
At 12:25 PM +1030 2003/02/24, Daniel O'Connor wrote: 802.11g isn't a final standard yet either (note no WiFi logo on 11g stuff) WiFi waffled. There probably won't be any kind of a WiFi logo on 11g equipment. Or 11a, for that matter. They're too beholden to corporate interests, and I don't think any interoperability tests of this sort will ever be conducted, or will ever be conductable. I remain willing to be convinced that I am wrong, however. Personally I'd wait a bit until the standard is finalised and the interoperability tests are done before buying any of it. Take some wool underwear with you if you go downstairs. ;-) -- Brad Knowles, <[EMAIL PROTECTED]> "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, Historical Review of Pennsylvania. GCS/IT d+(-) s:+(++)>: a C++(+++)$ UMBSHI$ P+>++ L+ !E-(---) W+++(--) N+ !w--- O- M++ V PS++(+++) PE- Y+(++) PGP>+++ t+(+++) 5++(+++) X++(+++) R+(+++) tv+(+++) b+() DI+() D+(++) G+() e++> h--- r---(+++)* z(+++) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: background fsck deadlocks with ufs2 and big disk
At 2:28 PM -0800 2003/02/20, Darryl Okahata wrote: Did you believe that the crashes were caused by enabling softupdates on an R5 vinum volume, or were the crashes unrelated to vinum/softupdates? I can see how crashes unrelated to vinum/softupdates might trash vinum filesystems. Using RAID-5 under vinum was always a somewhat tricky business for me, but in many cases I could get it to work reasonably well most of the time. But if I enabled softupdates on that filesystem, I was toast. Softupdates enabled on filesystems that were not on top of vinum RAID-5 logical devices seemed to be fine. So, the interaction that I personally witnessed was specifically between vinum RAID-5 and softupdates. -- Brad Knowles, <[EMAIL PROTECTED]> "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, Historical Review of Pennsylvania. GCS/IT d+(-) s:+(++)>: a C++(+++)$ UMBSHI$ P+>++ L+ !E-(---) W+++(--) N+ !w--- O- M++ V PS++(+++) PE- Y+(++) PGP>+++ t+(+++) 5++(+++) X++(+++) R+(+++) tv+(+++) b+() DI+() D+(++) G+() e++> h--- r---(+++)* z(+++) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: UFS2 regression tests?
At 7:58 PM -0500 2003/02/19, Wesley Morgan wrote: How about getting some tarballs full of tons of files, extracting them, deleting and randomly powering down forcing an fsck... :p Better yet, get that sample 1.7KB zip file that extracts out to hundreds of GB, and really thrash the system by doing parallel extracts of multiple copies of it, and make sure that you've got enough going at the same time that the result would be far larger than your available disk space. That should be fun! Not sure how much "regression" this provides but you're fairly likely to break something! Yeah, especially if it's UFS2, you're doing softupdates with background fsck, and you've used vinum to build the large logical volume. ;-) -- Brad Knowles, <[EMAIL PROTECTED]> "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, Historical Review of Pennsylvania. GCS/IT d+(-) s:+(++)>: a C++(+++)$ UMBSHI$ P+>++ L+ !E-(---) W+++(--) N+ !w--- O- M++ V PS++(+++) PE- Y+(++) PGP>+++ t+(+++) 5++(+++) X++(+++) R+(+++) tv+(+++) b+() DI+() D+(++) G+() e++> h--- r---(+++)* z(+++) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: UFS2 regression tests?
At 7:17 PM -0500 2003/02/19, John De Boskey wrote: So, does anyone have any comments/ideas on a good way to test the new system? You could always set it up as a full-feed USENET news server. Should be able to fill that sucker up in two or three days. ;-) Perhaps a freenet or other p2p filesharing server? You could also set it up as a freely available anonymous ftp read/write server. Or maybe a mirror of the various popular anonymous ftp sites out there? At least that'd give you a lot of data to write Perhaps you want to give Bonnie++, IOZone, IOBench, etc... a really big test set? Perhaps even set them up to run in continuous mode, so as to really thrash your disks as much as possible as quickly as possible? -- Brad Knowles, <[EMAIL PROTECTED]> "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, Historical Review of Pennsylvania. GCS/IT d+(-) s:+(++)>: a C++(+++)$ UMBSHI$ P+>++ L+ !E-(---) W+++(--) N+ !w--- O- M++ V PS++(+++) PE- Y+(++) PGP>+++ t+(+++) 5++(+++) X++(+++) R+(+++) tv+(+++) b+() DI+() D+(++) G+() e++> h--- r---(+++)* z(+++) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: background fsck deadlocks with ufs2 and big disk
At 9:15 AM -0800 2003/02/19, Darryl Okahata wrote: * The UFS1 filesystem in question (and I assume that it was UFS1, as I did not specify a filesystem type to newfs) is located on a RAID5 vinum volume, consisting of five 80GB disks. * Softupdates is enabled. You know, vinum & softupdates have had bad interactions with each other for as long as I can remember. Has this truly been a consistent thing (as I seem to recall), or has this been an on-again/off-again situation? -- Brad Knowles, <[EMAIL PROTECTED]> "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, Historical Review of Pennsylvania. GCS/IT d+(-) s:+(++)>: a C++(+++)$ UMBSHI$ P+>++ L+ !E-(---) W+++(--) N+ !w--- O- M++ V PS++(+++) PE- Y+(++) PGP>+++ t+(+++) 5++(+++) X++(+++) R+(+++) tv+(+++) b+() DI+() D+(++) G+() e++> h--- r---(+++)* z(+++) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: 5-STABLE Roadmap
At 9:47 PM -0800 2003/02/13, Sam Leffler wrote: SpecFS (NFS ops/sec benchmark) List price on SPEC SFS97 R1 is $900. And my recollection is that it was involved to setup and run. $450 for educational organizations. Wouldn't the FreeBSD Foundation qualify? Benchmarks must be unencumbered; be easy to setup+run by one person; and not require lots of equipment. For the most part we are looking for benchmarks that will help tune system performance; not generate press releases. Some of the more interesting benchmarks take more hardware to properly run. They're not necessarily particularly hard to setup, but they do want client machines to be used to generate test load. Rick Jones had to use 20 client machines with netperf in order to find the limits of performance for Nominum Authoritative Name Server (ANS), and he works for HP. I think you need to decide just how thorough you want your testing to be. If it's all going to be just single people running benchmarks on single machines, I think that there are going to be a lot of things you may miss. I have this problem myself with the benchmarks I've been running in conjunction with the invited talks I did at LISA 2002 and BSDCon Europe 2002, and people have repeatedly called me to task on this issue. -- Brad Knowles, <[EMAIL PROTECTED]> "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, Historical Review of Pennsylvania. GCS/IT d+(-) s:+(++)>: a C++(+++)$ UMBSHI$ P+>++ L+ !E-(---) W+++(--) N+ !w--- O- M++ V PS++(+++) PE- Y+(++) PGP>+++ t+(+++) 5++(+++) X++(+++) R+(+++) tv+(+++) b+() DI+() D+(++) G+() e++> h--- r---(+++)* z(+++) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: 5-STABLE Roadmap
At 8:28 PM -0800 2003/02/13, Sam Leffler wrote: This can quickly turn into a bikeshed, but suggest ones. We're looking for good benchmarks. lmbench, rawio, and bonniee are rather "micro" in nature (not bad, just limited in their usefulness). Well, I would submit that webstone and ApacheBench are rather "micro" in their nature as well -- they cover only one protocol, and/or one program. LMbench is, to the best of my knowledge, the very best low-level benchmark around for looking at things like system call overhead, process creation, signal handling, memory read latency, L1/2/3 sizing vs. speed trade-offs, TCP, UDP, and RPC latency & bandwidth, etc Since a lot of these things are likely to be changing with all the kernel changes in FreeBSD-5.x, this would seem to be a good candidate for the toolbox. The ATA & CAM drivers are getting updated too, not to mention additional work on softupdates and other filesystem-related features, so it would seem to me that you're really want a lot of disk benchmarks. RawIO is the only benchmark anywhere that I know of that looks at the underlying hardware performance for disk drives (by-passing all the OS caching, etc...). Bonnie++ is one of the better medium-level disk benchmarking tools, so that you can compare the raw numbers returned by RawIO against the "cooked" numbers returned by Bonnie++. If you want higher-level benchmarks, you could look at IOStone, IOZone, and/or IOBench. Postal is an interesting filesystem/disk benchmark, because it tests a very specific type of application load which is typically found in mail & news servers. If protocol-specific benchmarks might be of interest, then you could look at postal & rabid (SMTP & POP3), smtp-sink & smtp-source (SMTP transmit & receive), mstone (SMTP, POP3, IMAP, HTTP, etc...), or perhaps others. -- Brad Knowles, <[EMAIL PROTECTED]> "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, Historical Review of Pennsylvania. GCS/IT d+(-) s:+(++)>: a C++(+++)$ UMBSHI$ P+>++ L+ !E-(---) W+++(--) N+ !w--- O- M++ V PS++(+++) PE- Y+(++) PGP>+++ t+(+++) 5++(+++) X++(+++) R+(+++) tv+(+++) b+() DI+() D+(++) G+() e++> h--- r---(+++)* z(+++) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: 5-STABLE Roadmap
At 6:53 AM -0800 2003/02/14, Sam Leffler wrote: $450 for educational organizations. Wouldn't the FreeBSD Foundation qualify? The point was that they cost $$$. Not an option for many developers. Fair enough. Microbenchmarks are valuable here and have already been heavily used. Good. Can we get a more complete list of the microbenchmarks used, and perhaps get some consideration for some of the benchmarks I've mentioned? We're at the point where we need something that exercises the system on a bit larger scale. This indicates to me that LMbench might be a good choice for internal O/S & networking things, and that perhaps one of IOStone, IOBench, or IOZone might be good choices for exercising the disk subsystem. Eventually we'll get to the point where large-scale benchmarks are worth running. Large-scale, as in? Of course what we really need more than benchmarks are people to actually follow through on the results and fix the problems... I hope to be able to help in a more material fashion by being able to run some comparison benchmarks on my test system here, but I fear that I would not be able to help fix any problems that might be identified. -- Brad Knowles, <[EMAIL PROTECTED]> "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, Historical Review of Pennsylvania. GCS/IT d+(-) s:+(++)>: a C++(+++)$ UMBSHI$ P+>++ L+ !E-(---) W+++(--) N+ !w--- O- M++ V PS++(+++) PE- Y+(++) PGP>+++ t+(+++) 5++(+++) X++(+++) R+(+++) tv+(+++) b+() DI+() D+(++) G+() e++> h--- r---(+++)* z(+++) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: 5-STABLE Roadmap
At 4:36 PM -0800 2003/02/13, Scott Long wrote: - the classic 'worldstone' - webstone - /usr/ports/www/webstone - Fstress - http://www.cs.duke.edu/ari/fstress - ApacheBench - /usr/ports/www/p5-ApacheBench - netperf - /usr/ports/benchmarks/netperf Are there any other benchmarks that are being considered? What about LMBench? RawIO? Bonnie++? Other disk benchmarks? Do we care about application-layer benchmarks for other protocols, such as SMTP, POP3, or IMAP? Just curious. Thanks! -- Brad Knowles, <[EMAIL PROTECTED]> "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, Historical Review of Pennsylvania. GCS/IT d+(-) s:+(++)>: a C++(+++)$ UMBSHI$ P+>++ L+ !E-(---) W+++(--) N+ !w--- O- M++ V PS++(+++) PE- Y+(++) PGP>+++ t+(+++) 5++(+++) X++(+++) R+(+++) tv+(+++) b+() DI+() D+(++) G+() e++> h--- r---(+++)* z(+++) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: tmpfile breakage on setuid executables
At 4:23 PM -0800 2003/02/05, Terry Lambert wrote: I would never have thought of looking for zebras, since it worked on my 5.0 system, with all my test programs. This has been a very interesting conversation to watch. Can I assume that there will be some more regression tests set up that will test compiling all code with full warnings and the optimizer? Also, can someone explain to me what the heck a "zebra" is, in this context? -- Brad Knowles, <[EMAIL PROTECTED]> "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, Historical Review of Pennsylvania. GCS/IT d+(-) s:+(++)>: a C++(+++)$ UMBSHI$ P+>++ L+ !E-(---) W+++(--) N+ !w--- O- M++ V PS++(+++) PE- Y+(++) PGP>+++ t+(+++) 5++(+++) X++(+++) R+(+++) tv+(+++) b+() DI+() D+(++) G+() e++> h--- r---(+++)* z(+++) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Preview: GEOMs statistics code.
At 9:54 AM +0100 2003/02/05, [EMAIL PROTECTED] wrote: My understanding was that a disk is 100% busy, if the heads are constantly moving to and fro, and there is no period of time when they aren't being yanked around. In other words, it would be 100% if there is always at least one outstanding request. Works for me, I'll try if I can instrument that cheaply. I should be heading off to the office here shortly. Let me see if I can quote the relevant sections of the iostat man page for Solaris, with the hope that they will be able to explain more accurately and clearly just exactly what it is that they measure and what it means. I currently use binuptime() which means that the resolution is whatever the system provides, which means better than 1 microsecond on all current platforms. The counters are updated in real time, so it's up to you how often you read them. So, we're talking about some fairly significant modifications to iostat to get it to poll these values and be able to create some averages that it can report. Well, "tracelog" is simply my word for the concept of recording each and every transaction and run it through some kind of analysis afterwards. Ahh, I see. Thanks again! -- Brad Knowles, <[EMAIL PROTECTED]> "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, Historical Review of Pennsylvania. GCS/IT d+(-) s:+(++)>: a C++(+++)$ UMBSHI$ P+>++ L+ !E-(---) W+++(--) N+ !w--- O- M++ V PS++(+++) PE- Y+(++) PGP>+++ t+(+++) 5++(+++) X++(+++) R+(+++) tv+(+++) b+() DI+() D+(++) G+() e++> h--- r---(+++)* z(+++) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Preview: GEOMs statistics code.
At 8:26 AM +0100 2003/02/05, [EMAIL PROTECTED] wrote: Is a disk 100% busy if it has requests outstanding at all times, but could handle five times as many requests because they could be sorted into the current stream of requests free of cost ? Or is it only 20% busy ? How do you measure it ? My understanding was that a disk is 100% busy, if the heads are constantly moving to and fro, and there is no period of time when they aren't being yanked around. In other words, it would be 100% if there is always at least one outstanding request. Now, these requests could be sorted into a more efficient order and you could continue to get better performance out of a disk even though it is technically 100% busy, but that should show up as the throughput and number of transactions per unit of measurement time continuing to climb, while the %busy remains pegged. In this scenario, of real concern would be the average service time, %wait, and wait service time statistics. Once the %busy is pegged, %wait is climbing and wsvc_time also starts climbing, you've gotten to a point where there probably isn't anything more that you can squeeze out of that disk. If this situation persists for a significant period of time, then you probably want to get more spindles going for you so that you can eliminate this bottleneck. What is your time resolution on this sort of thing? Iostat can only report in periods as small as one update per second, so I would hope that you could measure these quantities on a much more frequent basis, thus being able to make a useful calculation of average values over that period of time. Responsetime on the other hand is a very reliable estimator of how long time you next request is going to take to handle. Right. That should be relatively low, so long as the disk is less than 100% busy. You still want to pay attention to it, but it shouldn't be much to worry about. The correct average queue length is close to a thousand, but the sampled number will be just one. It's random sampling. Without some comparatively expensive math in the kernel I don't think I can see a way to return the correct number. Give us the best you can, and let us know about the resolution issues. So long as we know, we should be okay. For truly trying to understand our disk-I/O load, tracelogs will be needed (And I fear they will show a lot of interesting phenomena). Hmm. I'd like to learn more about this tracelog concept. Can you provide any pointers? -- Brad Knowles, <[EMAIL PROTECTED]> "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, Historical Review of Pennsylvania. GCS/IT d+(-) s:+(++)>: a C++(+++)$ UMBSHI$ P+>++ L+ !E-(---) W+++(--) N+ !w--- O- M++ V PS++(+++) PE- Y+(++) PGP>+++ t+(+++) 5++(+++) X++(+++) R+(+++) tv+(+++) b+() DI+() D+(++) G+() e++> h--- r---(+++)* z(+++) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Preview: GEOMs statistics code.
At 1:07 AM +0100 2003/02/05, [EMAIL PROTECTED] wrote: I don't have a queue-depth as such, but I have number of transactions in transit. Will a snapshot of that at the time of the read do what you want ? I am too sleepy to know if that will allow you to calculate the average number of outstanding requests precisely. I would think that should do just fine. So long as we can get some sense of %busy (and %wait) as well as average service times (over the sample period), that should let us fill out those last columns in `iostat -x`. I won't be locking the stats counters, so reads may get inconsistent results. There is no risk for the updates, because all the updating happens in the g_up thread, so there is no contention for changing the kernel fields. The risk is that the copy passed to userland may happen in the middle of an update and therefore have a field with a weird value which will look OK at the next reading. The risk is quite small because the g_up thread has higher priority than anything coming in from userland will ever have. This is the same kind of risk that we have with `ps`, right? In that the data is in the process of changing as we are reading it, so you can't always take the data it prints out too literally? IMO, that's a perfectly fine limitation to live with, for the results that it allows us to get. -- Brad Knowles, <[EMAIL PROTECTED]> "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, Historical Review of Pennsylvania. GCS/IT d+(-) s:+(++)>: a C++(+++)$ UMBSHI$ P+>++ L+ !E-(---) W+++(--) N+ !w--- O- M++ V PS++(+++) PE- Y+(++) PGP>+++ t+(+++) 5++(+++) X++(+++) R+(+++) tv+(+++) b+() DI+() D+(++) G+() e++> h--- r---(+++)* z(+++) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Preview: GEOMs statistics code.
At 4:58 PM -0600 2003/02/04, Dan Nelson wrote: I pressume we also want to collect number of bytes transferred, and I will add that in the next iteration. Definitely. What I'd like is enough statistics to be able to duplicate Solaris' iostat -x output: You know, that is *precisely* what I was thinking! I'm glad someone else had the same idea -- Brad Knowles, <[EMAIL PROTECTED]> "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, Historical Review of Pennsylvania. GCS/IT d+(-) s:+(++)>: a C++(+++)$ UMBSHI$ P+>++ L+ !E-(---) W+++(--) N+ !w--- O- M++ V PS++(+++) PE- Y+(++) PGP>+++ t+(+++) 5++(+++) X++(+++) R+(+++) tv+(+++) b+() DI+() D+(++) G+() e++> h--- r---(+++)* z(+++) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Preview: GEOMs statistics code.
At 10:44 PM +0100 2003/02/04, Poul-Henning Kamp wrote: In difference from the devstat framework which measures how big a percentage of the time a drive has one or more outstanding requests, I think that measuring the responstime is a much more useful metric. (comments, input, references welcome) This is queue depth versus latency, right? I don't suppose a request to provide both would hold any weight with you, would it? -- Brad Knowles, <[EMAIL PROTECTED]> "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, Historical Review of Pennsylvania. GCS/IT d+(-) s:+(++)>: a C++(+++)$ UMBSHI$ P+>++ L+ !E-(---) W+++(--) N+ !w--- O- M++ V PS++(+++) PE- Y+(++) PGP>+++ t+(+++) 5++(+++) X++(+++) R+(+++) tv+(+++) b+() DI+() D+(++) G+() e++> h--- r---(+++)* z(+++) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: rand() is broken
At 4:41 PM -0800 2003/02/02, Terry Lambert wrote: Donald Knuth seemed to like them well enough to publish the algorithm, as part of his discussion on randomness. He *didn't* publish RC4, in that same discussion. RC stands for Ron's Code. This stuff came after the work that Diffie Hellman did, for which the patent expired a little while ago. Did RC4 even exist at the time that Don published that book? -- Brad Knowles, <[EMAIL PROTECTED]> "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, Historical Review of Pennsylvania. GCS/IT d+(-) s:+(++)>: a C++(+++)$ UMBSHI$ P+>++ L+ !E-(---) W+++(--) N+ !w--- O- M++ V PS++(+++) PE- Y+(++) PGP>+++ t+(+++) 5++(+++) X++(+++) R+(+++) tv+(+++) b+() DI+() D+(++) G+() e++> h--- r---(+++)* z(+++) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: split out patch
At 6:27 PM -0800 2003/02/01, Matthew Dillon wrote: Well, it is an active conversation/thread. Either people care enough to stay involved or they don't. But don't people have to sleep sometime? Shouldn't we allow for that? I mean, I can understand impatience, too. I get impatient when I've done things and I'm waiting on other people to respond. I guess I'm just trying to find out what level of impatience would be appropriate in this kind of situation -- given the amount of time that had passed and the specific day and hours in question. -- Brad Knowles, <[EMAIL PROTECTED]> "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, Historical Review of Pennsylvania. GCS/IT d+(-) s:+(++)>: a C++(+++)$ UMBSHI$ P+>++ L+ !E-(---) W+++(--) N+ !w--- O- M++ V PS++(+++) PE- Y+(++) PGP>+++ t+(+++) 5++(+++) X++(+++) R+(+++) tv+(+++) b+() DI+() D+(++) G+() e++> h--- r---(+++)* z(+++) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: split out patch
At 10:47 AM -0800 2003/02/01, Julian Elischer wrote: still no comments? this patch seems to be working, but a review from another developer would be good.. particularly re: the point mentionned.. You first announced the split-out patch at Sat, 1 Feb 2003 02:59:24 -0800 (PST). The date/time stamp on the message that I am replying to is Sat, 1 Feb 2003 10:47:44 -0800 (PST). That's something around seven hours and forty-five minutes, unless I have miscalculated. Is it really normal to expect replies within that kind of a time frame, especially since we're talking about 3:00 AM to 10:45 AM, and most people are likely to be asleep? Granted, not everyone is in PST, but it's still a relatively quiet period of time for most people outside of Asia, and we don't seem to have a whole lot of people from those time zones on this list. I'm not questioning the patch at all, just the apparent impatience. If I am wrong and it is normal to expect a reasonable response within this period of time and within this particular period of time on a Saturday morning, please let me know. -- Brad Knowles, <[EMAIL PROTECTED]> "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, Historical Review of Pennsylvania. GCS/IT d+(-) s:+(++)>: a C++(+++)$ UMBSHI$ P+>++ L+ !E-(---) W+++(--) N+ !w--- O- M++ V PS++(+++) PE- Y+(++) PGP>+++ t+(+++) 5++(+++) X++(+++) R+(+++) tv+(+++) b+() DI+() D+(++) G+() e++> h--- r---(+++)* z(+++) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: postfix equiv. of sendmail's -bH?
At 8:08 PM -0500 2003/01/18, Kutulu wrote: I was just concerned that some useful task that used to occur nightly may now not be occurring, and if so, what I could do to make it occur again. I didn't see anything to even indicate that postfix has a host status cache, meaning the option is pretty pointless either way. I was just wondering if anyone who had run postfix longer than me knew for sure :) I think the closest that postfix has for the sendmail "host status" feature is the fast_flush_domains parameter, but this is normally only used for those domains that you will be acting as a backup MX/relay host and only works in conjunction with the ETRN command. With sendmail, IIRC you can use the host status information both for domains that you act as a backup MX for, as well as for domains that you do a lot of e-mail with. Therefore, they don't quite serve the same function. The fast_flush_domains feature is something Wietse added after several people (myself included) complained that there was no easy way to do the equivalent of a "sendmail -qRdomain.com", either from the command-line or via the ETRN command. Instead, he used to just flush the entire queue. Imagine you're an ISP running a backup MX for tens of thousands or hundreds of thousands of clients, and you see an average of 5-10 ETRN commands per second. Then think about trying to flush the entire queue each time you get an ETRN. Of course, postfix has built-in methods of restricting the number of SMTP clients that can be attempting to deliver mail to any given user or domain, so it has less of a need for something like a HostStatusDirectory. My understanding is that the fast_flush_domains stuff works through having the system log data related to the $relay_domains parameter in a certain way so that you can keep track of which file/message is bound for which recipient domain(s), and so that you can then figure out which files need to be flushed when you get an ETRN. I don't think there's a way to flush this feature in postfix, short of stopping and starting the service. However, I'll have to check the latest source code to be sure. -- Brad Knowles, <[EMAIL PROTECTED]> "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, Historical Review of Pennsylvania. GCS/IT d+(-) s:+(++)>: a C++(+++)$ UMBSHI$ P+>++ L+ !E-(---) W+++(--) N+ !w--- O- M++ V PS++(+++) PE- Y+(++) PGP>+++ t+(+++) 5++(+++) X++(+++) R+(+++) tv+(+++) b+() DI+() D+(++) G+() e++> h--- r---(+++)* z(+++) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Re[2]: 80386 out of GENERIC
At 4:45 PM -0800 2002/12/15, Avleen Vig wrote: How difficult would the following be to develop, in your opinion? A boot disk image (like the sets of images on the website tm) that will boot on 386's as well as more modern CPU's that can newfs and disklabel your drives, download the source, and let you compile from that point. How many uninterrupted days/weeks would you be willing to allow a "make world" to run? something to compile with - which can be downloaded with the source all precompile so the do work on all x86 CPU's. If you're compiling the code (as would be necessary, since 386-compatible code would not be included in any of the regular binaries), then there is no such thing as "pre-compiled" anything. Morever, the concept of compiling something is mutually exclusive to getting a pre-compiled copy of that same something. -- Brad Knowles, <[EMAIL PROTECTED]> "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, Historical Review of Pennsylvania. GCS/IT d+(-) s:+(++)>: a C++(+++)$ UMBSHI$ P+>++ L+ !E-(---) W+++(--) N+ !w--- O- M++ V PS++(+++) PE- Y+(++) PGP>+++ t+(+++) 5++(+++) X++(+++) R+(+++) tv+(+++) b+() DI+() D+(++) G+() e++> h--- r---(+++)* z(+++) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: FBSD 5.0RC1 install oddity
At 9:23 PM +0100 2002/12/15, Claudio Nieder wrote: Problem: After that question the install programm immediatly tries to contact the DHCP server, which cannot work, as informations like the WEP key to use etc. were asked for/supplied so that the wireless card could be properly set up to communicate. I ran into this same problem when I was trying to install FreeBSD-4.6.2-RELEASE. I think that the solution is actually to flip to a different page in the sysinstall program and provide the additional options that you need. Unfortunately, although I think I stumbled into this solution, I couldn't tell you how to replicate it. -- Brad Knowles, <[EMAIL PROTECTED]> "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, Historical Review of Pennsylvania. GCS/IT d+(-) s:+(++)>: a C++(+++)$ UMBSHI$ P+>++ L+ !E-(---) W+++(--) N+ !w--- O- M++ V PS++(+++) PE- Y+(++) PGP>+++ t+(+++) 5++(+++) X++(+++) R+(+++) tv+(+++) b+() DI+() D+(++) G+() e++> h--- r---(+++)* z(+++) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: TTL
At 9:14 PM -0800 2002/12/13, Jimi Thompson wrote: With the increasing complexity of the internet, this is often a problem for those who have large internal networks and/or live in Australia. 30 hops often isn't enough to make to the core DNS. It probably ought to be extended to something more realistic. The other numbers that I've seen used 64, 128, and 256. We ran into this problem in '96, when I was working at AOL. We had a guy in California who wanted to send e-mail to his friend across the hall, but of course those packets had to traverse the country to be delivered to our servers in Virginia. We went back and forth a few times, and I even set up tcpdump on the particular machine I told him to connect directly to -- I could see his packets coming in, but our responses were never received. Turns out that, by a quirk of routing fate, he was something like 32 hops away, and while his OS was fine, our particular patch revision of HP-UX 9 was hard-coded at 30. We applied a later patch to the machines, and everything went back to normal. This is not a new problem. Unfortunately, many OSes may still have inappropriate values defined. -- Brad Knowles, <[EMAIL PROTECTED]> "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, Historical Review of Pennsylvania. GCS/IT d+(-) s:+(++)>: a C++(+++)$ UMBSHI$ P+>++ L+ !E-(---) W+++(--) N+ !w--- O- M++ V PS++(+++) PE- Y+(++) PGP>+++ t+(+++) 5++(+++) X++(+++) R+(+++) tv+(+++) b+() DI+() D+(++) G+() e++> h--- r---(+++)* z(+++) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: RC NG, ntp and routed
At 5:41 PM -0800 2002/12/11, Tim Kientzle wrote: The point of the barrier scripts is to provide simple dependencies to other scripts. In particular, NETWORKING should represent a fully-functional network, including any routing or multicast routing that is normally used on this network. It does not, in itself, depend on any filesystems. (It runs no programs itself, so why would it?) Sure it does. In order to do anything, you have to run programs -- right? And where do those programs come from -- a filesystem, right? And what if that filesystem is not local, but mounted via NFS? So, you need a way to bootstrap the early parts of networking before mounting the later filesystems. -- Brad Knowles, <[EMAIL PROTECTED]> "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, Historical Review of Pennsylvania. GCS/IT d+(-) s:+(++)>: a C++(+++)$ UMBSHI$ P+>++ L+ !E-(---) W+++(--) N+ !w--- O- M++ V PS++(+++) PE- Y+(++) PGP>+++ t+(+++) 5++(+++) X++(+++) R+(+++) tv+(+++) b+() DI+() D+(++) G+() e++> h--- r---(+++)* z(+++) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: RC NG, ntp and routed
At 10:33 PM -0800 2002/12/10, Gordon Tetlow wrote: DISKS FILESYSTEMS NETWORKING DAEMON LOGIN DISKS would be things that are needed to get the disks in order to start getting filesystems mounted (vinum, ccd, raidframe and friends). It may be a superflous step. FILESYSTEMS and NETWORKING are a problem because they kind of intertwine. It's not a clear cut case of mount all the filesystems then start the networking interfaces. In reality, FILESYSTEMS and NETWORKING are very much muddled (and cause me no end of grief as a result). DAEMON is for things like ssh and the like that need to run (thinking about nfsd, sshd, and just about any *d) LOGIN is just that. Things that are started at the end of system initialization. I believe that DISKS should be split into DISKS_LOCAL and DISKS_NETWORK. This allows us to get NETWORKING going after DISKS_LOCAL and before DISKS_NETWORK. We may also want to split NETWORKING into INTERFACES and ROUTING (and higher level networking), in case there is anything that we might need to slide in-between. We might even need to split NETWORKING into three parts. I'd like to think about really sitting down and overhauling the rc.d system after 5.0 is branched. I think that it's reasonable to say we should not try to be compatible with NetBSD except for keeping a common rc.subr and major initialization catagories (basically anything that is in all caps). Does anyone have a problem with dyking out the NetBSD specific portions after 5.0? Nope. It's nice to be as close as we can feasibly get, but if it doesn't work then it doesn't work, and we shouldn't unnecessarily handicap ourselves just to be compatible. -- Brad Knowles, <[EMAIL PROTECTED]> "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, Historical Review of Pennsylvania. GCS/IT d+(-) s:+(++)>: a C++(+++)$ UMBSHI$ P+>++ L+ !E-(---) W+++(--) N+ !w--- O- M++ V PS++(+++) PE- Y+(++) PGP>+++ t+(+++) 5++(+++) X++(+++) R+(+++) tv+(+++) b+() DI+() D+(++) G+() e++> h--- r---(+++)* z(+++) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: RC NG, ntp and routed
At 11:23 AM -0200 2002/12/09, Daniel C. Sobral wrote: I do see one contraindication to this behavior. Most routing protocols also react badly to time changes. Egg and chicken problem, but, personally, and running OSPF, which is one of those protocols that react badly to time changes, I find it preferably to run the router first. IIRC, ntpd should not cause large-scale changes to the time that might wreak havoc with your router. It should only be making changes in the rate at which the clock ticks, so as to speed it up or slow it down, to the point where you are more or less in sync with your reference(s). It would be ntpdate that would be the potentially dangerous one making large-scale changes to your system time. Therefore, you definitely want the router stuff before the ntpd stuff. -- Brad Knowles, <[EMAIL PROTECTED]> "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, Historical Review of Pennsylvania. GCS/IT d+(-) s:+(++)>: a C++(+++)$ UMBSHI$ P+>++ L+ !E W+++(--) N+ !w--- O- M++ V PS++(+++) PE- Y+(++) PGP>+++ t+(+++) 5++(+++) X++(+++) R+(+++) tv+(+++) b+() DI+() D+(++) G+() e++> h--- r---(+++)* z(+++) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Any ideas at all about network problem?
At 10:33 PM -0500 2002/12/04, Craig Reyenga wrote: Unfortunately, I have no extra hardware available to me, so I can't experiment with switches and whatnot. Also, wouldn't some sort of software experimentation be more appropriate, considering that my existing setup works _perfetcly_ in 4.7? At the very least, try hard-wiring the configuration at both ends to be 100Mbps full-duplex. There's a chance that 4.7 and 5.0 will handle auto-negotiation differently. Other than that, you should try swapping out as much hardware as you can -- the cards, the cables, etc If possible, you should also test with other computers (in case the problem is with one specific machine when it is running 5.0). Just because something appears to work perfectly in another OS is not an indication that there is not anything wrong with that setup. If that was the case, there would never be a need for any replacement for any Microsoft OSes, because many vendors stop trying to debug the problem when they can prove that things work just fine under Windows. I'm not sure what to do; should I be trying various versions of if_rl.c? Or is there something else that I should be trying? If you really want to try swapping software, you'll have to do a binary search on each potential piece of software involved. However, since there are many potential software components that could be involved, while testing each component individually between now and then should theoretically be doable in 10 tests (as previously mentioned), the combinatorial explosion will be exceptionally nasty. -- Brad Knowles, <[EMAIL PROTECTED]> "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, Historical Review of Pennsylvania. GCS/IT d+(-) s:+(++)>: a C++(+++)$ UMBSHI$ P+>++ L+ !E W+++(--) N+ !w--- O- M++ V PS++(+++) PE- Y+(++) PGP>+++ t+(+++) 5++(+++) X++(+++) R+(+++) tv+(+++) b+() DI+() D+(++) G+() e++> h--- r---(+++)* z(+++) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Any ideas at all about network problem?
At 12:31 PM +0200 2002/12/03, [EMAIL PROTECTED] wrote: The two machines involved are connected by a crossover cable: I've heard of lots of problems with machines using cross-over cables. Can you connect the machines through a switch, and ensure that they are hard-wired to 100Base-TX full duplex at both ends, as opposed to auto-negotiating? I'll try a different cable this evening when I get home. Is there a minimum length? The cable is currently 2m long. I'm prepared to do any other debugging people here can suggest to make it work faster. FWIW my single CPU workstaion at the office running 4.7-STABLE with an fxp0 NIC does not suffer the same throughput reduction. I've also heard of lots of problems with some machines when the cable is too short, at least in certain combinations. Try successively longer lengths of cable, at least up to 20-30m. -- Brad Knowles, <[EMAIL PROTECTED]> "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, Historical Review of Pennsylvania. GCS/IT d+(-) s:+(++)>: a C++(+++)$ UMBSHI$ P+>++ L+ !E W+++(--) N+ !w--- O- M++ V PS++(+++) PE- Y+(++) PGP>+++ t+(+++) 5++(+++) X++(+++) R+(+++) tv+(+++) b+() DI+() D+(++) G+() e++> h--- r---(+++)* z(+++) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Any ideas at all about network problem?
At 3:32 PM -0700 2002/12/02, Cliff L. Biffle wrote: One thing I've used in the past that improves Realtek throughput is forcing the media type and duplex setting on both ends of the connection. Autodetect in the 8139s seems to be unreliable at times. This is true for most 10/100 Base-T implementations I've seen. None of them have been able to reliably auto-detect. Any time I hear someone complain of network throughput problems, this is one of the first things I have them check. However, this would not seem to be the case in this instance, unless 4.7 and 5.x are not handling auto-detect in the same way. -- Brad Knowles, <[EMAIL PROTECTED]> "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, Historical Review of Pennsylvania. GCS/IT d+(-) s:+(++)>: a C++(+++)$ UMBSHI$ P+>++ L+ !E W+++(--) N+ !w--- O- M++ V PS++(+++) PE- Y+(++) PGP>+++ t+(+++) 5++(+++) X++(+++) R+(+++) tv+(+++) b+() DI+() D+(++) G+() e++> h--- r---(+++)* z(+++) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Any ideas at all about network problem?
At 12:55 AM -0500 2002/12/02, Craig Reyenga wrote: I just tried a 3com 3c905 NIC (my roommate's) and it _also_ transfers slowly (about 3.5MB/sec, so just under half of what i used to get with my realtek in -stable). It also spit out a few messages: According to all the source modules I've read regarding RealTek cards, they're about the biggest pieces of hardware garbage that has ever been inflicted on the free/open community. However, a 3Com card should be a little better. Have you tried replacing both RealTek cards with 3Com, to see if that changes things? I'd really rather not play around with different versions of FreeBSD to fix this problem, because this computer is where I keep all of my stuff, and with exams, I just won't have the time. Yes I know that I "shouldn't be using 5.0 then" but a problem is a problem and it should be fixed. Yeah, well. Regrettably, while 5.x-CURRENT needs as many testers as it can get before 5.0-RELEASE, it is not something that people should be using for critical work. I agree that this is a problem, but what we need right now are people who can help us find problems (which you've done) but then can also go the next steps and help us locate the problem (which you are unwilling or unable to do). As soon as I get a couple of other things squared away, I'm going to take the leap myself and start trying to run -CURRENT, but with the commitment that I will do everything I can to locate any bugs that I find. But this means that I need to make sure that my FreeBSD box is doing useful (but not critical) stuff, so that I can give it a semi "real world" test. At the very least, try DP1. If that doesn't work, then the changes happened somewhere earlier, and they will be more difficult to track down. Either that, or the problem is actually somewhere else, and you're only seeing the results through your network transfers. -- Brad Knowles, <[EMAIL PROTECTED]> "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, Historical Review of Pennsylvania. GCS/IT d+(-) s:+(++)>: a C++(+++)$ UMBSHI$ P+>++ L+ !E W+++(--) N+ !w--- O- M++ V PS++(+++) PE- Y+(++) PGP>+++ t+(+++) 5++(+++) X++(+++) R+(+++) tv+(+++) b+() DI+() D+(++) G+() e++> h--- r---(+++)* z(+++) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Problem pulling particular directory from CVS
At 1:27 PM -0800 2002/11/29, Paul A. Scott wrote: Damn. I keep forgetting about the Mac OSX stupid, case-insesitive HFS+. Yeah, I've bitched about this for years. I mean, HFS was an improvement over MFS (can you imagine a filesystem structure that keeps everything at one level and doesn't use directories at all?), but they really blew chunks on this. Of course, HFS+ is only a minor improvement over HFS. But then, HFS is way, way better than MS-DOS 8.3, which is what it was being compared with at the time. Ya know, Apple stated on their Web site, "there is never any good reason to have a case-sensitive file system." Can you believe that? I wrote back to them and stated, "there is never any good reason to have a case-INsensitive filesystem." But, of course, they never replied. :) Try bitching at Jordan. Maybe he can get them to fix UFS instead. -- Brad Knowles, <[EMAIL PROTECTED]> "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, Historical Review of Pennsylvania. GCS/IT d+(-) s:+(++)>: a C++(+++)$ UMBSHI$ P+>++ L+ !E W+++(--) N+ !w--- O- M++ V PS++(+++) PE- Y+(++) PGP>+++ t+(+++) 5++(+++) X++(+++) R+(+++) tv+(+++) b+() DI+() D+(++) G+() e++> h--- r---(+++)* z(+++) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: -current unusable after a crash
At 2:02 PM -0800 2002/11/25, Terry Lambert wrote: If you made system dumps mandatory (or marked swap with a non-dump header in case of panic), this still would not handle the "silent reboot", "double panic", or "single panic with disk I/O trashed" cases. 8-(. How about we do the safe thing, and only do background fsck if we can prove that the system state is something where it would be suitable? Or would that mean that we almost never do background fsck? -- Brad Knowles, <[EMAIL PROTECTED]> "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, Historical Review of Pennsylvania. GCS/IT d+(-) s:+(++)>: a C++(+++)$ UMBSHI$ P+>++ L+ !E W+++(--) N+ !w--- O- M++ V PS++(+++) PE- Y+(++) PGP>+++ t+(+++) 5++(+++) X++(+++) R+(+++) tv+(+++) b+() DI+() D+(++) G+() e++> h--- r---(+++)* z(+++) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: gcc 3.2.1 release import?
At 1:53 AM +0200 2002/11/24, Vallo Kallaste wrote: But who will bell the cat? I vote for Snuffles. Don't understand. Some inside joke or something based on US centric TV? What are you trying to tell me? Remember I'm not native. I am a native US citizen (well, caucasian ;-), and I don't get the reference. Maybe it's something regional, or perhaps something that only the older folks will get. Anyway, I think that he was trying to make is that it's all well and good to talk about doing the debugging, etc..., but the real question is who is sufficiently clueful and has the spare cycles to do all this work in such a short period of time? Frankly, I would be willing to bet large sums of money that it won't happen. Indeed, my vote would be to not attempt to make it happen, and allow for gcc 3.2.1 (or whatever) to be incorporated into -CURRENT after the 5.0-RELEASE. Better the devil you know than the devil you don't. -- Brad Knowles, <[EMAIL PROTECTED]> "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, Historical Review of Pennsylvania. GCS/IT d+(-) s:+(++)>: a C++(+++)$ UMBSHI$ P+>++ L+ !E W+++(--) N+ !w--- O- M++ V PS++(+++) PE- Y+(++) PGP>+++ t+(+++) 5++(+++) X++(+++) R+(+++) tv+(+++) b+() DI+() D+(++) G+() e++> h--- r---(+++)* z(+++) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Searching for users of netncp and nwfs to help debug5.0 problems
At 1:04 PM -0800 2002/11/23, Nate Lawson wrote: I'd like to see this on in 5.0 for a while, given the number of new users and problem reports we are already getting and will soon get even more of. If it's too hard to complete this work, could we add DDB in by default in GENERIC? (I shudder to think at the amount of debate such a request would cause but I'm making it nevertheless). IMO, for -CURRENT, we should turn on all possible debugging by default in the kernel. Then, we should make it as easy as possible to capture and report the kind of trace information we need to help locate and fix the problem. Hmm. I was thinking that I needed just one Cyclades terminal server box for my old Sun SPARC 5 clone (break-safe, of course). Now, I'm thinking that I'll need a multi-port model, which I can also connect to the Compaq Armada 4131T that I'll be running -DP2 on, and given all the network problems I've had lately, I may need to also connect it to the cisco ISDN/Ethernet router -- Brad Knowles, <[EMAIL PROTECTED]> "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, Historical Review of Pennsylvania. GCS/IT d+(-) s:+(++)>: a C++(+++)$ UMBSHI$ P+>++ L+ !E W+++(--) N+ !w--- O- M++ V PS++(+++) PE- Y+(++) PGP>+++ t+(+++) 5++(+++) X++(+++) R+(+++) tv+(+++) b+() DI+() D+(++) G+() e++> h--- r---(+++)* z(+++) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Searching for users of netncp and nwfs to helpdebug5.0 problems
At 10:39 PM -0800 2002/11/22, Terry Lambert wrote: In terms of kernel problems, the absolutely most useful information is the DDB traceback, followed by a DDB traceback mapped against a debug kernel, followed by a system dump image and a debug kernel, etc.. By default, the system, as distributed, is not setup to supply this. This was kind of my point. Each OS is going to need different things to be easily gathered and reported, and in this case I think we need to enable more information more easily available regarding kernel panics and crash dumps, etc The MacOS X model does not directly apply here. What we want is the concept of taking the important information and making it as easy as possible to collect and report. Plus we aren't really talking about -CURRENT, we are talking about "5.0-DP2", or "almost 5.0-RC1", if we're being honest. I understand. Indeed, this is the issue that has brought me into this subject -- my wanting to be able to contribute (but not being able to do so through coding), and Mark observing that my skills in beating the hell out of things might be useful in helping to debug the upcoming -RELEASE. These kinds of things get all that much more important when we're talking about a -RELEASE coming up. -- Brad Knowles, <[EMAIL PROTECTED]> "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, Historical Review of Pennsylvania. GCS/IT d+(-) s:+(++)>: a C++(+++)$ UMBSHI$ P+>++ L+ !E W+++(--) N+ !w--- O- M++ V PS++(+++) PE- Y+(++) PGP>+++ t+(+++) 5++(+++) X++(+++) R+(+++) tv+(+++) b+() DI+() D+(++) G+() e++> h--- r---(+++)* z(+++) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Searching for users of netncp and nwfs to help debug5.0 problems
At 2:31 PM -0800 2002/11/22, Terry Lambert wrote: A "bug-filing wizard" would be useful. The "send-pr" system doesn't cut it, and most people are unaware of how to file a decent bug report. It doesn't help when the process involves another computer, a serial cable, recompiling a kernel to use a serial console and turn DDB support on, special configuration for system dump images, and changing the size of your swap partition to support the amount of RAM you have put into the machine. Speaking as someone who is about to step off the deep end and start trying to actually run and test -CURRENT on my system here at home, I believe that this kind of resource would be vitally important. In contrast, I've had a few crashes this past week from other programs here on my PowerBook G4 running MacOS X (primarily Chimera, based on the Mozilla Gecko engine with native Aqua interface), and they have made it very easy for me to report crashes. They have integrated tools to extract the maximum amount of information from the system as to exactly what other programs were running, what the program stack was, and a whole host of other things. All I have to do is type in my e-mail address, optionally describe what I was trying to do at the time, and have a functioning Internet connection so that they can upload the reports. I'd share some examples with you, but they are *huge*. Now, we can say that running -CURRENT is not for people who want to be molly-coddled. But I believe it's a good idea to give people better tools to help make a better system. I am convinced that we can find a better compromise. If the PR contains a patch, and the owner does nothing in the allotted time, then give the PR submitter a commit bit, and give ownership of the area over to them. At the very least, PR's will be closed, and more people actively writing code will end up with commit bits. Gack. I'm not sure even I would be quite this radical -- any moron (like me ;-) can generate a PR that might include a patch. IMO, better would be to give the area to another person who is suitably qualified, has the available cycles, and presumably already has a commit bit. -- Brad Knowles, <[EMAIL PROTECTED]> "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, Historical Review of Pennsylvania. GCS/IT d+(-) s:+(++)>: a C++(+++)$ UMBSHI$ P+>++ L+ !E W+++(--) N+ !w--- O- M++ V PS++(+++) PE- Y+(++) PGP>+++ t+(+++) 5++(+++) X++(+++) R+(+++) tv+(+++) b+() DI+() D+(++) G+() e++> h--- r---(+++)* z(+++) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Searching for users of netncp and nwfs to help debug5.0 problems
At 6:45 PM -0500 2002/11/21, Robert Watson wrote: I appreciate the effort, and am interested in the idea, but in this case it was as much a solicitation for a developer as for the testing environment itself. This won't just be "testing" of netncp and nwfs, this will probably require a developer to have local access to a netware configuration that they can do nasty things to in order to exercise the code properly. Unfortunately, those seem to be in short supply. I understand. My understanding is that part of the job of this team is to find people that have various different types of environments that could be used for testing like this, and put them together with the necessary development personnel. If I might suggest: there's a freebsd-qa mailing list. It's a great place to organize QA efforts, whereas freebsd-chat is notorious for its lack of signal (it's where dead signals go to rot). There's been some talk of freebsd-qa, but so far the only thing I recall being said is that the sort of thing we're talking about doing is not what this list has been used for in the past. We were kind of wondering where we could take this particular effort, and if we could commandeer the freebsd-qa list for this purpose. If you moving the conversation there and get a bunch of people subscribed and interested, they'll be able to look there for the stream of bug fixes associated with the install process, and get easy access to the testing guide as it evolves, since we usually pass drafts through there, etc. We will be moving the conversation to somewhere more appropriate, but I don't know when or where. I believe that our biggest problem at the moment is finding the necessary development types to help us debug the problems and get them sorted out -- we've got people who have hardware, and would be more than willing to help test things out, but in the past they haven't gotten much help from the developers. -- Brad Knowles, <[EMAIL PROTECTED]> "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, Historical Review of Pennsylvania. GCS/IT d+(-) s:+(++)>: a C++(+++)$ UMBSHI$ P+>++ L+ !E W+++(--) N+ !w--- O- M++ V PS++(+++) PE- Y+(++) PGP>+++ t+(+++) 5++(+++) X++(+++) R+(+++) tv+(+++) b+() DI+() D+(++) G+() e++> h--- r---(+++)* z(+++) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Searching for users of netncp and nwfs to help debug5.0 problems
At 5:23 PM -0500 2002/11/21, Robert Watson wrote: (And, you have to bring your own test environment, as the second sentence suggests, but doesn't actually state). Over on -chat, we're in the process of putting together a list of volunteers, hardware, organizational talent, etc... to help test out -DP2. Mark Murray is involved, but I personally would like to see at least one or two more core team members committed to making this happen. If we can get a suitable group of people together, with suitable hardware, and get the coordination effort done correctly, I believe that we can help make this a much more successful project. Your assistance in this effort would be greatly appreciated. -- Brad Knowles, <[EMAIL PROTECTED]> "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, Historical Review of Pennsylvania. GCS/IT d+(-) s:+(++)>: a C++(+++)$ UMBSHI$ P+>++ L+ !E W+++(--) N+ !w--- O- M++ V PS++(+++) PE- Y+(++) PGP>+++ t+(+++) 5++(+++) X++(+++) R+(+++) tv+(+++) b+() DI+() D+(++) G+() e++> h--- r---(+++)* z(+++) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Run two copies of named from rc.conf?
At 4:41 PM -0800 2002/11/18, Terry Lambert wrote: But. If you are transiently connected, then if the on site DNS server is authoritative, then there is no way to look up externally hosted services via DNS, unless the external DNS, also a hosted service, and therefore not transiently connected, is authoritative. Sorry, I wasn't think of transient networks. Indeed, that does make things a lot uglier. I'll have to think some more about all the various implications, however. -- Brad Knowles, <[EMAIL PROTECTED]> "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, Historical Review of Pennsylvania. GCS/IT d+(-) s:+(++)>: a C++(+++)$ UMBSHI$ P+>++ L+ !E W+++(--) N+ !w--- O- M++ V PS++(+++) PE- Y+(++) PGP>+++ t+(+++) 5++(+++) X++(+++) R+(+++) tv+(+++) b+() DI+() D+(++) G+() e++> h--- r---(+++)* z(+++) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Run two copies of named from rc.conf?
At 10:01 PM -0800 2002/11/17, Terry Lambert wrote: Interior and exterior DNS is a useful case; however, there are multiple ways to set it up; in general, it's not possible to have interior authoritative DNS at the same time you have exterior authoritative DNS (this was a mistake we made on the InterJet, for a long time), without modifying the DNS server to forward requests for which it has incomplete information (e.g. the "PNS" draft RFC I wrote). It depends on how you do it. You could $INCLUDE the exterior file inside the interior file, if that subset of information is the same. You could also use BIND 9 "views". Otherwise, split-horizon can be a pain. -- Brad Knowles, <[EMAIL PROTECTED]> "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, Historical Review of Pennsylvania. GCS/IT d+(-) s:+(++)>: a C++(+++)$ UMBSHI$ P+>++ L+ !E W+++(--) N+ !w--- O- M++ V PS++(+++) PE- Y+(++) PGP>+++ t+(+++) 5++(+++) X++(+++) R+(+++) tv+(+++) b+() DI+() D+(++) G+() e++> h--- r---(+++)* z(+++) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Run two copies of named from rc.conf?
At 9:15 PM -0800 2002/11/17, Juli Mallett wrote: Or at least abstracting it in such a way that it doesn't get in anyone's way, and so it won't trigger the "what if I need N" where N>2 case, and in some meaningful way... Like maybe using a named_configs lists, and start one named for each config, or something. Yeah, I was definitely thinking of a much more general solution. IMO, the switch should either be "One" or "Many", with perhaps an easy way to degenerate a "Many" solution to more easily serve the "One" case. -- Brad Knowles, <[EMAIL PROTECTED]> "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, Historical Review of Pennsylvania. GCS/IT d+(-) s:+(++)>: a C++(+++)$ UMBSHI$ P+>++ L+ !E W+++(--) N+ !w--- O- M++ V PS++(+++) PE- Y+(++) PGP>+++ t+(+++) 5++(+++) X++(+++) R+(+++) tv+(+++) b+() DI+() D+(++) G+() e++> h--- r---(+++)* z(+++) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: New NVidia drivers on -current
At 9:11 AM +0100 2002/11/18, David Holm wrote: BTW, why hasn't anyone set the mailing list to automatically set the reply-to address to [EMAIL PROTECTED]? <http://www.unicom.com/pw/reply-to-harmful.html>. -- Brad Knowles, <[EMAIL PROTECTED]> "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, Historical Review of Pennsylvania. GCS/IT d+(-) s:+(++)>: a C++(+++)$ UMBSHI$ P+>++ L+ !E W+++(--) N+ !w--- O- M++ V PS++(+++) PE- Y+(++) PGP>+++ t+(+++) 5++(+++) X++(+++) R+(+++) tv+(+++) b+() DI+() D+(++) G+() e++> h--- r---(+++)* z(+++) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: POSTFIX-- Wietse: tweak and go! --pkg & port: both duds
At 9:22 PM + 2000/10/8, attila! wrote: > I look at 'snapshots' philosophically; if I willingly track > FreeBSD-5.0-current, I am obviously accustomed to the risks > therein. Understood. I just wanted to point out the philosophical differences from the postfix perspective, and thought that it was important that this be made explicit. > 20001001 is the most current which Wietse is now running and > stating that it is 'production quality'. Obviously, I will > port 20001001 this afternoon! No, 20001005 is the latest snapshot I know of, and appears to be what Wietse is running himself: $ telnet spike.porcupine.org. 25 Trying 168.100.189.2... Connected to spike.porcupine.org. Escape character is '^]'. 220 spike.porcupine.org ESMTP Postfix (Snapshot-20001005) quit 221 Bye Connection closed by foreign host. However, I would not be too surprised if what he was running is actually slightly later than this (i.e., another snapshot in progress), and it just identifies itself as Snapshot-20001005. > Why not consider the use of the mysql interface which > provides dynamic aliasing? The machines where I run this code don't strictly need a MySQL interface for aliases. Although we do keep our internal aliases in a MySQL database, I do not believe that it is in a format that would be suitable for use with postfix, and therefore I'd have to create yet another MySQL database that *was* in the proper format. This would likely lead to synchronization problems, etc -- These are my opinions -- not to be taken as official Skynet policy ========== Brad Knowles, <[EMAIL PROTECTED]>|| Belgacom Skynet SA/NV Systems Architect, Mail/News/FTP/Proxy Admin || Rue Colonel Bourg, 124 Phone/Fax: +32-2-706.13.11/12.49 || B-1140 Brussels http://www.skynet.be || Belgium "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, Historical Review of Pennsylvania. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: POSTFIX-- Wietse: tweak and go! --pkg & port: both duds
At 2:31 PM -0500 2000/10/8, Will Andrews wrote: > Heh.. Wietse uses so-called ``experimental'' Postfix on his systems. > And there are *LOTS* of people who think that whatever Wietse runs is > good enough for them.. so this statement had better be hased on personal > experience about the actual stability of ``experimental''. I quoted directly from the postfix web page, when I said that the snapshot versions are: Work-in-progress code, subject to change, needs testing before it can become an official release. I've been involved with postfix since long before it became known by this name, and all during that process, the recommended version that people are encouraged to run is the latest "official release" version. Myself, I run the next-to-latest snapshot version on our production systems, but you'd better be prepared to deal with any problems that may occur if you want to do the same. Otherwise, you shouldn't be running a snapshot version. -- These are my opinions -- not to be taken as official Skynet policy ====== Brad Knowles, <[EMAIL PROTECTED]>|| Belgacom Skynet SA/NV Systems Architect, Mail/News/FTP/Proxy Admin || Rue Colonel Bourg, 124 Phone/Fax: +32-2-706.13.11/12.49 || B-1140 Brussels http://www.skynet.be || Belgium "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, Historical Review of Pennsylvania. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: POSTFIX-- Wietse: tweak and go! --pkg & port: both duds
At 7:02 AM + 2000/10/8, attila! wrote: > (a) pick a directory and 'tar -zxf snapshot-2531.tar.gz' > > (b) 'cd snapshot-2531' Three things: 1. You don't tell people where to get the postfix software. Start with <http://www.postfix.org/ftp-sites.html>, and select a mirror site close to you. 2. You mention the use of snapshots, but this is not recommended practice for sites new to postfix. Instead, start with the most recent "release" version, e.g., postfix-19991231-pl09. According to Wietse, the "snapshot" versions are: Work-in-progress code, subject to change, needs testing before it can become an official release. However, these versions are what he runs on his own systems, so it's probably better than the official "production" release version of code from most anyone else. 3. If you want to build postfix with libraries that Wietse does not consider "standard" for your platform, this will take just a bit more work. I have a "MAKEAS" script that I keep at the root of my /usr/local/src/postfix directory structure, and whenever I go to build a new version, I just execute: $ sh ../MAKEAS And it does all the "hard" preparation work for me, which I can then just follow up with a: $ make; sh INSTALL.sh According to the instructions. Currently, my MAKEAS script contains the following (with backslashes to escape the line-breaks I manually added to prevent mis-wrapping): make makefiles CCARGS="-I/usr/local/BerkeleyDB/include \ -DHAS_DB -DPATH_DB_H='' \ -L/usr/local/BerkeleyDB/lib" AUXLIBS="-ldb" \ LDFLAGS="-L/usr/local/BerkeleyDB/lib" LIBS="-ldb" \ SYSLIBS="-ldb" Note that this implies that on this machine I have previously built and installed the Berkeley db 2.7.7 (built with "../dist/configure --enable-compat185", because postfix uses only the db 1.85 interfaces) and BIND 8.2.2-P5 (or whatever the latest version is that you want to install) packages. Note that Berkeley db 3.0 installs in a slightly different directory, and that I've had problems with it causing runtime failures, etc Recent snapshot releases have added features for performing simple one line body_check regexp matching (like the older header_check), added support for DSNs, and a new "fast ETRN" feature that will avoid flushing the entire queue when a single site wants mail for them to be flushed (which now makes postfix more suitable for use at an ISP that provides backup MX services for its customers). -- These are my opinions -- not to be taken as official Skynet policy == Brad Knowles, <[EMAIL PROTECTED]>|| Belgacom Skynet SA/NV Systems Architect, Mail/News/FTP/Proxy Admin || Rue Colonel Bourg, 124 Phone/Fax: +32-2-706.13.11/12.49 || B-1140 Brussels http://www.skynet.be || Belgium "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, Historical Review of Pennsylvania. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: DPT SmartRAID V, VI, Adaptec SCSI RAID driver committed
At 11:25 AM -0700 2000/9/5, Mike Smith wrote: > http://people.freebsd.org/~msmith/RAID/index.html#dpt Awesome! Thanks! Now I just have to get FreeBSD 4.2 installed on that ftp server -- These are my opinions -- not to be taken as official Skynet policy == Brad Knowles, <[EMAIL PROTECTED]>|| Belgacom Skynet SA/NV Systems Architect, Mail/News/FTP/Proxy Admin || Rue Colonel Bourg, 124 Phone/Fax: +32-2-706.13.11/12.49 || B-1140 Brussels http://www.skynet.be || Belgium "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, Historical Review of Pennsylvania. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: DPT SmartRAID V, VI, Adaptec SCSI RAID driver committed
At 1:22 PM -0700 2000/9/4, Mike Smith wrote: > I'd like to hear a few more success stories first (only one so far) from > people using the kit to add the driver to their 4.x systems. With all > the breakage in -current's PCI support at the moment, I don't expect to > hear too many people there reporting on it just yet. Well, if I can find a sufficiently stable -STABLE to install on my anonymous ftp server, I'll be glad to give it a try. > That's the general plan. Cool! I can't wait! -- These are my opinions -- not to be taken as official Skynet policy ====== Brad Knowles, <[EMAIL PROTECTED]>|| Belgacom Skynet SA/NV Systems Architect, Mail/News/FTP/Proxy Admin || Rue Colonel Bourg, 124 Phone/Fax: +32-2-706.13.11/12.49 || B-1140 Brussels http://www.skynet.be || Belgium "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, Historical Review of Pennsylvania. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: DPT SmartRAID V, VI, Adaptec SCSI RAID driver committed
At 1:30 AM -0700 2000/9/1, Mike Smith wrote: > I've just committed a driver for the abovementioned RAID adapter families > provided by DPT/Adaptec and the long-suffering Mark Salyzyn. The driver > will be maintained by Adaptec, with a little help from yours truly if > really necessary. Excellent! Any ideas when this might be MFC'd to -STABLE? > With any luck, we should see the complete set of management tools > available from Adaptec shortly to complement this driver, and I'll be > backporting to -stable once I'm certain I haven't broken anything with > this commit, since the driver's already had a long shakedown period. Awesome! You mean that we won't have to reboot into DOS (or PROM) to manage reconfigure this thing? Cool! > Thanks to Adaptec, Mark Salyzyn and Justin Gibbs for again being the right > person in the right place at the right time. And thanks to you, for all your hard work that you've put in to make all the various RAID adaptors function correctly under FreeBSD! We couldn't do it without you, Mike! -- These are my opinions -- not to be taken as official Skynet policy ====== Brad Knowles, <[EMAIL PROTECTED]>|| Belgacom Skynet SA/NV Systems Architect, Mail/News/FTP/Proxy Admin || Rue Colonel Bourg, 124 Phone/Fax: +32-2-706.13.11/12.49 || B-1140 Brussels http://www.skynet.be || Belgium "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, Historical Review of Pennsylvania. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: SMP and softupdates?
At 7:36 PM + 2000/8/28, Alex Zepeda wrote: > Perhaps in a rush to get started, I've compiled and > been using a SMP kernel even before the second processor arrives. This > has worked fine, however I've gotten some rather weird hangs and crashes > resulting in a nice lost+found directory on the usr fs. Personally, I'm astonished that an SMP kernel will actually boot and run on a uniprocessor machine. Before pointing any fingers at softupdates, etc... I think that the first thing I'd do on this machine is switch back to using a real uniprocessor kernel, and then see if I could replicate the problems. -- These are my opinions -- not to be taken as official Skynet policy ========== Brad Knowles, <[EMAIL PROTECTED]>|| Belgacom Skynet SA/NV Systems Architect, Mail/News/FTP/Proxy Admin || Rue Colonel Bourg, 124 Phone/Fax: +32-2-706.13.11/12.49 || B-1140 Brussels http://www.skynet.be || Belgium "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, Historical Review of Pennsylvania. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: DPT revision....(broken drivers in -STABLE)
At 11:07 PM -0700 2000/8/26, Mike Smith wrote: > The Linux driver for the V and VI cards is (according to a reliable > source) pretty awful. I've had to keep making modifications to them to get them to compile with newer and newer versions of the kernel, and while I keep contributing those changes back, they never seem to see the light of day. ;-( > I have theoretically production-quality drivers from Adaptec which I will > be committing as soon as I have time to test them (a few days, I hope). Cool! I can't wait! Is there anything I can do to help? -- These are my opinions -- not to be taken as official Skynet policy ====== Brad Knowles, <[EMAIL PROTECTED]>|| Belgacom Skynet SA/NV Systems Architect, Mail/News/FTP/Proxy Admin || Rue Colonel Bourg, 124 Phone/Fax: +32-2-706.13.11/12.49 || B-1140 Brussels http://www.skynet.be || Belgium "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, Historical Review of Pennsylvania. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: DPT revision....(broken drivers in -STABLE)
At 10:18 PM -0400 2000/8/23, Matthew N. Dodd wrote: > I don't remember seeing a verbose boot log posted so I can't really say > whats wrong. There is no difference b/t the -CURRENT and 4-STABLE > versions of dpt_pci.c so I'm not sure what could be causing the > problem. Of course it may be that the cards don't work in -CURRENT > either. I'm curious -- what kinds of cards are supported by this routine? Does this include the DPT SmartRAID V, as well as the older SmartRAID IV? I've got an anonymous ftp server I need to rebuild -- it had previously been running Slackware Linux, but as the kernel got updated, the source for the driver didn't, so I scrapped it and am rebuilding with FreeBSD. Anyway, my thought was actually to scrap the DPT card (because it was my understanding that the FreeBSD drivers for the SmartRAID V were only "beta" quality), and simply use vinum instead. However, if this card is better supported than I first thought, then I'll be glad to keep it. ;-) -- These are my opinions -- not to be taken as official Skynet policy ====== Brad Knowles, <[EMAIL PROTECTED]>|| Belgacom Skynet SA/NV Systems Architect, Mail/News/FTP/Proxy Admin || Rue Colonel Bourg, 124 Phone/Fax: +32-2-706.13.11/12.49 || B-1140 Brussels http://www.skynet.be || Belgium "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, Historical Review of Pennsylvania. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: bin/19635: add -c for grand total to df(1), like du(1)does
At 12:41 PM +0200 2000/7/6, Sheldon Hearn wrote: > Filesystem Size Used Avail Capacity Mounted on > mfs:26 87M11K80M 0%/tmp > /dev/ad0s1f 1.2G 934M 241M80%/usr > /dev/ad0s1e 193M92M86M52%/var > /dev/ccd0c 1.8G 786M 900M47%/a > /dev/ad1s1e 1.3G 728M 474M61%/b > procfs 4.0K 4.0K 0B 100%/proc > rodent.ops:/home/ncvs 3.4G 3.1G36M99%/usr/home/ncvs > > In particular, I can't believe that 87M - 11K == 80M (I'd expect 86M or > 87M). Nor is it credible that 1.8G - 786 == 900M (I'd expect 1057M or > 1G). You're ignoring the fact that "Size" is the total physical size of the device, while "Used", "Avail", and "Capacity" take into account the 10% (or whatever) overhead that is typically left unallocated for performance reasons. Thus, when "Capacity" shows that ~110% is used, and "Used" == "Size", then you are really and truly completely full on that device. -- These are my opinions -- not to be taken as official Skynet policy == Brad Knowles, <[EMAIL PROTECTED]>|| Belgacom Skynet SA/NV Systems Architect, Mail/News/FTP/Proxy Admin || Rue Colonel Bourg, 124 Phone/Fax: +32-2-706.13.11/12.49 || B-1140 Brussels http://www.skynet.be || Belgium To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: bin/19635: add -c for grand total to df(1), like du(1)does
At 9:21 PM -0400 2000/7/3, Will Andrews wrote: > Does anyone else here think this is a good idea? If you're looking for votes, you've got mine. BTW, will this play nicely with -h? Consider me stupid if you like, but I've recently been re-re-re-re-reading the man pages for df(1), and ran across this option I had never heard of before, and I quite like the way it adaptively summarizes the information. Of course, now that you've got me started, I have to go re-re-re-re-read the du(1) man page, too. ;-) Thanks! -- These are my opinions -- not to be taken as official Skynet policy ====== Brad Knowles, <[EMAIL PROTECTED]>|| Belgacom Skynet SA/NV Systems Architect, Mail/News/FTP/Proxy Admin || Rue Colonel Bourg, 124 Phone/Fax: +32-2-706.13.11/12.49 || B-1140 Brussels http://www.skynet.be || Belgium To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: cvs commit: src/sys/contrib/softupdates softdep.hffs_softdep.c
At 10:30 AM +0200 2000/6/22, Adrian Chadd wrote: > I like this. Would anyone object if this was brought over from NetBSD ? If you're asking for a vote, you've got mine. -- These are my opinions -- not to be taken as official Skynet policy ====== Brad Knowles, <[EMAIL PROTECTED]>|| Belgacom Skynet SA/NV Systems Architect, Mail/News/FTP/Proxy Admin || Rue Colonel Bourg, 124 Phone/Fax: +32-2-706.13.11/12.49 || B-1140 Brussels http://www.skynet.be || Belgium To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: Destabilization due to SMP development
At 5:00 PM -0400 2000/6/21, Dan Papasian wrote: > Eivind Elkund was talking about doing something like > this. He had a pretty nice document about it, > too. If I recall, the name was "OVCS: Open Version Control System" Hmm. So far, Google hasn't been particularly useful in trying to track this stuff down. The first page that came up was <http://www.cyclic.com/CVS/index_html>, which is for the "Open Source Version Control Software" page (i.e., good ole' CVS itself), and the next search turned up <http://www.ovcs.org/>, which is the page for "Otselic Valley Central School". Doing a bit more digging, I did finally manage to find <http://people.FreeBSD.org/~eivind/DeveloperStation.txt>, and although it has his name and the magic "ocvs" characters, I don't think this is quite what I'm looking for, either. So far, the most useful page I've found on this topic is <http://www.advogato.org/person/eivind/>, but all it does is mention: Notes: I'm a FreeBSD developer, presently on sabbatical. For my sabbatical, I'm working on a new version control system, aimed at distributed development. Does anyone have any real information or useful pointers on exactly what he's working on right now, and what the current state of that project is? Thanks! -- These are my opinions -- not to be taken as official Skynet policy == Brad Knowles, <[EMAIL PROTECTED]>|| Belgacom Skynet SA/NV Systems Architect, Mail/News/FTP/Proxy Admin || Rue Colonel Bourg, 124 Phone/Fax: +32-2-706.13.11/12.49 || B-1140 Brussels http://www.skynet.be || Belgium To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: Destabilization due to SMP development
At 11:09 PM +0200 2000/6/21, Mark Murray wrote: >> Has anyone given any thought to what it would take to create an >> open source version of something similar to perforce? ;-) > > Clearly you have. :-). We await your submissions with baited breath... If you're waiting for me on this, you might want to buy your burial plot now and go ahead and make all your final arrangements -- you're going to be waiting for a while. ;-) -- These are my opinions -- not to be taken as official Skynet policy ========== Brad Knowles, <[EMAIL PROTECTED]>|| Belgacom Skynet SA/NV Systems Architect, Mail/News/FTP/Proxy Admin || Rue Colonel Bourg, 124 Phone/Fax: +32-2-706.13.11/12.49 || B-1140 Brussels http://www.skynet.be || Belgium To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: Destabilization due to SMP development
At 9:34 PM +0200 2000/6/21, Soren Schmidt wrote: > Using a non opensource commercial version control system is just > to ask for bad carma, extended murphy fields and whatnot in an > opensource volounteer project... Has anyone given any thought to what it would take to create an open source version of something similar to perforce? ;-) -- These are my opinions -- not to be taken as official Skynet policy ====== Brad Knowles, <[EMAIL PROTECTED]>|| Belgacom Skynet SA/NV Systems Architect, Mail/News/FTP/Proxy Admin || Rue Colonel Bourg, 124 Phone/Fax: +32-2-706.13.11/12.49 || B-1140 Brussels http://www.skynet.be || Belgium To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: Destabilization due to SMP development
At 11:53 AM -0700 2000/6/19, Jason Evans wrote: > Last week, approximately 20 BSD developers got together and discussed how > to move FreeBSD's SMP support to the next level. Our effort will be > largely based on the work that has been done in BSD/OS, which should make > things go much more smoothly than they otherwise might, but we still expect > -current to be destabilized for an extended period of time. Wow. Cool. Way cool. My mind is already beginning to boggle, just thinking of what very little I know of what must go into a process like this On a totally non-technical, but somewhat related note, can anyone give me any kind of idea how often relatively "large scale" changes like this typically occur with FreeBSD? By the time I came along, I think -CURRENT was already well into 4.x, so I don't have that kind of history to fall back on. I'm just intensely curious to know how often "revolutions" of this kind of scale typically happen within this project. I can't wait to see the discussions go on with relation to all this stuff! However, if you don't mind I think I'll continue to track RELENG_4 and listen over here to get some idea of what may be ultimately coming down the pike over there for -STABLE. -- These are my opinions -- not to be taken as official Skynet policy ====== Brad Knowles, <[EMAIL PROTECTED]>|| Belgacom Skynet SA/NV Systems Architect, Mail/News/FTP/Proxy Admin || Rue Colonel Bourg, 124 Phone/Fax: +32-2-706.13.11/12.49 || B-1140 Brussels http://www.skynet.be || Belgium To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
