jail(8) should not set login name for session
jail(8) sets a new login name for the session if the command is run as another user and this affects parent/sibling programs. This error is described and a patch attached in http://www.freebsd.org/cgi/query-pr.cgi?pr=94730 Meanwhile an additional idea came into my mind and this is the reason for this mail: Should jail(8) create a new session via setsid(2) if the argument -l is supplied? BTW: The mentioned PR has Confidential set to yes. I don't know where it comes from, may be I become mad. :-( Regards, Frank -- Frank Behrens, Osterwieck, Germany PGP-key 0x5B7C47ED on public servers available. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: newbus questions
On Thu, 16/03/2006 at 15:48 +0100, Milan Obuch wrote:
Looks like I'm totally newbie there. I've created small saa_if.m
file,
with CODE section, declaring two small debug functions, and two METHODS,
DEFAULTing to that functions. Now I want to update Makefile so that
typing ``make depend'' will produce .c and .h from the .m file. Looks
like /sys/conf/kmod.mk lists all .m files by name, and deals with them
on one-by-one basis, so I must manually insert all that awk -f ...
invocations for these targets, am I right?
Not necessarily. You should put saa_if.m into kmod.mk, yes, but you should
actually somewhere use it.
Or had I overlooked feature of automated codegeneration just in
Makefile?
Could you show your Makefile? I think you are missing something there - like
saa_if.h and saa_if.c, maybe...
well, I've just added 'saa_if.c saa_if.m' to SRCS, and defined two
targets:
.m.h:
awk -f @/tools/makeobjops.awk ${.ALLSRC} -h
.m.c:
awk -f @tools/makeobjops.awk ${.ALLSRC} -c
and now it works.
I would also like to thank you for tip to call device_add_child
manually, after that my subdriver automatically found the device to
probe.
P.S. I suppose, that it's worth to create some useful doc with skeleton
bus driver, one dummy method, and child driver overriding that method.
(As to me, the latest task is the easiest, at least I know how to do
this, e.g., PCI device overriding probe method).
Any idea how? Maybe manpage patch? You know, every one welcomed :)
I think it will be a small article, with skeleton of bus device driver
and skeleton of driver for device on that bus, since that is really easy
once you know how.
P.P.S Hey, that's my birthday! So I would like a toast to all BSD
developers, core team and hackers
Mnoga ljeta, mnoga ljeta, mnoga ljeta... :)
Thanks!
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
creating install media on usb drive
Hi, I'm wanting to create a custom install on a 1gb USB thumb drive. I've done an install to the the USB thumb drive using the a option to use the entire disk, and then labeled one slice using entire disk, leaving no space for swap, and installed the Minimal FreeBSD install. The drive boots and works beautifully, able to customize, and run. I have already used it for recovery of a failed install. Next I removed the contents of the drive, cpio'ed the contents of the 5.4-i386 iso disc1. I then copied in the driver for my raid array, and modified boot/defaults/loader.conf to load the driver. The drive boots and configures the system, but when I try to tell it were to install from, I can't seem to be able to tell sysinstall where the install media is. I've tried setting the install to filesystem and / and no media is found. I've googled, and searched the freebsd mailing archives. Any help on this would be greatly appreciated. A.G. -- ___ A.G. Russell IV KC5KFDThe Knife Company e-mail: ag4 @ theknifecompany.com Phone 479-631-0055 FAX 479-631-8734 --- ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: creating install media on usb drive
On 3/20/06, A.G. Russell IV [EMAIL PROTECTED] wrote: Next I removed the contents of the drive, cpio'ed the contents of the 5.4-i386 iso disc1. I then copied in the driver for my raid array, and modified boot/defaults/loader.conf to load the driver. The drive boots and configures the system, but when I try to tell it were to install from, I can't seem to be able to tell sysinstall where the install media is. I've tried setting the install to filesystem and / and no media is found. It seems to me that you might have the problem where the thumbdrive shows up as da0 when you boot it by itself and dawhatever when the raid array is around. You've got a few ways to fix this. The old way would be to use hints to force the thumbdrive to be da0. The new way would be to create your filesystems with the '-L' argument to newfs and have 'geom_label' load in loader.conf. This will allow you to mount /dev/ufs/labelname as root rather than da0s1a ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
repeatedly opening the same .so(s) is slow?
Hello, Sorry if the subject is misleading, not sure how to label this one. I have a port (gnucash) which takes 3-4 minutes to open on a 2.6GHz machine. It used to take 15-20 seconds till all of the libtool changes. I have no idea if the symptom is related to libtool or not. Others have said it is not... but that's when the problems began, just for reference. FWIW, when I had trouble due to libtool, I simply formatted my machine, reinstalled OS and all ports. So this issue is occurring on a 'clean' machine. But here is what I have found, and it looks odd to me. Using truss, I can see that gnucash/guile is trying to open a dozen or two files, repeatedly. It fails attempting to open it the first few times everytime it tries to access it, because it is traversing the LD_LIBRARY_PATH: open(/lib/libglib-12.la,0x0,0666) ERR#2 'No such file or directory' open(/usr/lib/libglib-12.la,0x0,0666) ERR#2 'No such file or directory' open(/usr/local/lib/libglib-12.la,0x0,0666)ERR#2 'No such file or directory' open(/usr/X11R6/lib/gnucash/libglib-12.la,0x0,0666) ERR#2 'No such file or directory' open(/usr/X11R6/lib/libglib-12.la,0x0,0666)ERR#2 'No such file or directory' open(/usr/X11R6/lib/gnucash/libglib-12.la,0x0,0666) ERR#2 'No such file or directory' open(/usr/local/lib/libglib-12.la,0x0,0666)ERR#2 'No such file or directory' open(/lib/libglib-12.la,0x0,0666) ERR#2 'No such file or directory' open(/usr/lib/libglib-12.la,0x0,0666) ERR#2 'No such file or directory' open(/usr/local/lib/libglib-12.la,0x0,0666)ERR#2 'No such file or directory' open(/usr/X11R6/lib/gnucash/libglib-12.la,0x0,0666) ERR#2 'No such file or directory' open(/usr/X11R6/lib/libglib-12.la,0x0,0666)ERR#2 'No such file or directory' open(/usr/X11R6/lib/gnucash/libglib-12.la,0x0,0666) ERR#2 'No such file or directory' open(/usr/local/lib/libglib-12.la,0x0,0666)ERR#2 'No such file or directory' open(/lib/libglib-12.la,0x0,0666) ERR#2 'No such file or directory' open(/usr/lib/libglib-12.la,0x0,0666) ERR#2 'No such file or directory' open(libglib-12.la,0x0,0666) ERR#2 'No such file or directory' access(/lib/libglib-12.so,4) ERR#2 'No such file or directory' access(/usr/lib/libglib-12.so,4) ERR#2 'No such file or directory' access(/usr/local/lib/libglib-12.so,4) = 0 (0x0) Now I said a dozen or two files repeatedly. It is 12-20 files maybe... but it is attempting to open them *hundreds of thousands of times*! It goes on and on and on... I am assuming this is what is causing the long startup time. So I have been working towards helping it find the right files the first time around. I have manipulated the gnucash environments LD_LIBRARY_PATH a bit and helped some... but it is only a drop in the bucket. I have thought of placing symlinks in the folder(s) where it first looks for any given file, to make sure it finds the file... but this does not seem quite right either. What I'm wondering is what is the lists opinion on how to best fix this type of a problem. Is this even the cause of my long startup? I have spoken with one or two of the gnucash devs, they seem to think this is unique to FreeBSD, meaning they have not seen this problem on any other platform. They said it might have to do with how FreeBSD handles how files are opened up many times recursively!? If there is a more appropriate list, please let me know. Thanks in advance. -- Regards, Eric ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [RFE] dhclient(8) should send hostname
Frank Behrens [EMAIL PROTECTED] wrote on 18 Mar 2006 11:26: Brooks Davis [EMAIL PROTECTED] wrote on 17 Mar 2006 11:20: On Fri, Mar 17, 2006 at 04:02:17PM +0100, Frank Behrens wrote: I propose a change, that dhclient sends always the current hostname to the server, the value can be overwritten in dhclient.conf. I see no negative impact, because the server has always the possibility to reject the name and to choose another one. It would simplify the setup and lead to the same behaviour as in other (operating) systems. A possible (I'm sure not the best) solution I appended as attachment. I'm inclined to add this feature, possibly with an option to turn it off. It seems like a useful default and it's what other OSes do. I don't believe the objection above has much relevance since the actual update if any is only performed if the DHCP server is configured to make one. Incorrect DHCP packets sent by DHCP servers are my problem. Side effects caused by misconfiguration is not. Yes, this is my intention. The dhcp server gets from a client always the MAC address and - with my proposal - the clients host name as additional information. The decision what to make with this information has to make the dhcp server (administrator). It can make dynamic DNS updates or not. Meanwhile I made a short investigation about other systems and created a PR. All info can you read at http://www.freebsd.org/cgi/query-pr.cgi?pr=94743 It would give me great pleasure, if somebody could improve our dhcp client. Regards, Frank -- Frank Behrens, Osterwieck, Germany PGP-key 0x5B7C47ED on public servers available. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: repeatedly opening the same .so(s) is slow?
On Mon, 2006-Mar-20 10:49:57 -0600, Eric Schuele wrote: I have a port (gnucash) which takes 3-4 minutes to open on a 2.6GHz machine. It used to take 15-20 seconds till all of the libtool changes. It takes 15 minutes on a -current Athlon XP-1800 and about 2 minutes on a 2.2GHz AMD64 running -stable. I have no idea if the symptom is related to libtool or not. I initially thought it was libtool related but now I'm uncertain. I didn't just upgrade libtool, I upgraded quite a few other ports at the same time. On the not-libtool side, ade@ says that he hasn't seen this behaviour with other libtool/libltdl ports and I've found that guile include it's own libltdl code (based on libtool). I'm not sure if this is gnucash specific or affects other guile applications. Using truss, I can see that gnucash/guile is trying to open a dozen or two files, repeatedly. It fails attempting to open it the first few times everytime it tries to access it, because it is traversing the LD_LIBRARY_PATH: Worse than that, it's expanding LD_LIBRARY_PATH using additional paths embedded in the .la files that it's opening. Now I said a dozen or two files repeatedly. It is 12-20 files maybe... but it is attempting to open them *hundreds of thousands of times*! It goes on and on and on... I took a complete ktrace of the startup and there are 24e6 NAMI events with the top files tested 2,000,000 times. I have thought of placing symlinks in the folder(s) where it first looks for any given file, to make sure it finds the file... but this does not seem quite right either. It's definitely a hack. I tried something like this and it didn't help much. The code still wants to open libraries multiple times. I've been looking at adding caching to lt_dlopenext() and my first attempt went much faster but blew up because I wasn't correctly handling open/close/open sequences (libm is opened and then closed 42,000 times). I think this is the way forward but need to find the time to understand ltdl.[ch] (~4800 lines). What I'm wondering is what is the lists opinion on how to best fix this type of a problem. Is this even the cause of my long startup? Any system calls involving opening pathnames are expensive, even with the namei cache. Having 4 orders of magnitude too many is a destinct problem. I have spoken with one or two of the gnucash devs, they seem to think this is unique to FreeBSD, meaning they have not seen this problem on any other platform. They said it might have to do with how FreeBSD handles how files are opened up many times recursively!? Possibly Linux can more efficiently handle opening a non-existent file but the underlying problem is that there are far too many system calls being executed during the gnucash startup. It would be interesting to get a truss of gnuash starting on another OS (unfortunately, I don't have access to any Linux systems) and/or some other guile applications. If there is a more appropriate list, please let me know. -ports may be better. -- Peter Jeremy ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: repeatedly opening the same .so(s) is slow?
On Mon, Mar 20, 2006 at 10:49:57AM -0600, Eric Schuele wrote: I have a port (gnucash) which takes 3-4 minutes to open on a 2.6GHz machine. It used to take 15-20 seconds till all of the libtool changes. This sounds exactly like the problems I initially had with KDE on DragonFly. Check whether it is using libtool's dlopen wrapper, since it seems to believe that the system dlopen either can't support hard-coded search paths (known bug in the last 1.5 version of libtool) or can't trace dependency libs. Joerg ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: repeatedly opening the same .so(s) is slow?
Peter Jeremy wrote: On Mon, 2006-Mar-20 10:49:57 -0600, Eric Schuele wrote: I have a port (gnucash) which takes 3-4 minutes to open on a 2.6GHz machine. It used to take 15-20 seconds till all of the libtool changes. It takes 15 minutes on a -current Athlon XP-1800 and about 2 minutes on a 2.2GHz AMD64 running -stable. I have no idea if the symptom is related to libtool or not. I initially thought it was libtool related but now I'm uncertain. I didn't just upgrade libtool, I upgraded quite a few other ports at the same time. On the not-libtool side, ade@ says that he hasn't seen this behaviour with other libtool/libltdl ports and I've found that guile include it's own libltdl code (based on libtool). I'm not sure if this is gnucash specific or affects other guile applications. FWIW... I have removed my symlink to libguile-ltdl.so and recreated it to point at libltdl.so.1. So that guile is using my stock libltdl.so. I get the same results. And gnucash seems to run fine. Using truss, I can see that gnucash/guile is trying to open a dozen or two files, repeatedly. It fails attempting to open it the first few times everytime it tries to access it, because it is traversing the LD_LIBRARY_PATH: Worse than that, it's expanding LD_LIBRARY_PATH using additional paths embedded in the .la files that it's opening. Now I said a dozen or two files repeatedly. It is 12-20 files maybe... but it is attempting to open them *hundreds of thousands of times*! It goes on and on and on... I took a complete ktrace of the startup and there are 24e6 NAMI events with the top files tested 2,000,000 times. I have thought of placing symlinks in the folder(s) where it first looks for any given file, to make sure it finds the file... but this does not seem quite right either. It's definitely a hack. I tried something like this and it didn't help much. The code still wants to open libraries multiple times. I've been looking at adding caching to lt_dlopenext() and my first attempt went much faster but blew up because I wasn't correctly handling open/close/open sequences (libm is opened and then closed 42,000 times). I think this is the way forward but need to find the time to understand ltdl.[ch] (~4800 lines). What I'm wondering is what is the lists opinion on how to best fix this type of a problem. Is this even the cause of my long startup? Any system calls involving opening pathnames are expensive, even with the namei cache. Having 4 orders of magnitude too many is a destinct problem. I have spoken with one or two of the gnucash devs, they seem to think this is unique to FreeBSD, meaning they have not seen this problem on any other platform. They said it might have to do with how FreeBSD handles how files are opened up many times recursively!? Possibly Linux can more efficiently handle opening a non-existent file but the underlying problem is that there are far too many system calls being executed during the gnucash startup. It would be interesting to get a truss of gnuash starting on another OS (unfortunately, I don't have access to any Linux systems) and/or some other guile applications. hmm... I have a Gentoo system somewhere. It was just an experiment. No idea what shape its in. But maybe I can try installing gnucash on it. If there is a more appropriate list, please let me know. -ports may be better. -- Regards, Eric ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
IAL COMPETION ERROR on hptmv ( fixed )
After working with the dev's at Highpoint they have found fixed the bug where you get the following error: kernel: IAL: COMPLETION ERROR, adapter 0, channel 2, flags=104 kernel: ATA regs: error 10, sector count 1, LBA low ff, LBA mid ff, LBA high ff, device 4f, status 51 The issue was down to the Seagate drive firmware when accessing the 1024^3 byte. Previously the driver was using 28bit addressing for this but it was being rejected by the ST3400832AS disks. This has now been changed so that if the device can use 48bit addressing it is always used. I'm sure highpoint will be releasing this driver update shortly but in the mean time if anyone needs it contact me and I'll mail it you. Steve This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone (023) 8024 3137 or return the E.mail to [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: repeatedly opening the same .so(s) is slow?
Peter Jeremy wrote: On Mon, 2006-Mar-20 10:49:57 -0600, Eric Schuele wrote: I have a port (gnucash) which takes 3-4 minutes to open on a 2.6GHz machine. It used to take 15-20 seconds till all of the libtool changes. It takes 15 minutes on a -current Athlon XP-1800 and about 2 minutes on a 2.2GHz AMD64 running -stable. I have no idea if the symptom is related to libtool or not. I initially thought it was libtool related but now I'm uncertain. I didn't just upgrade libtool, I upgraded quite a few other ports at the same time. On the not-libtool side, ade@ says that he hasn't seen this behaviour with other libtool/libltdl ports and I've found that guile include it's own libltdl code (based on libtool). I'm not sure if this is gnucash specific or affects other guile applications. Using truss, I can see that gnucash/guile is trying to open a dozen or two files, repeatedly. It fails attempting to open it the first few times everytime it tries to access it, because it is traversing the LD_LIBRARY_PATH: Worse than that, it's expanding LD_LIBRARY_PATH using additional paths embedded in the .la files that it's opening. Now I said a dozen or two files repeatedly. It is 12-20 files maybe... but it is attempting to open them *hundreds of thousands of times*! It goes on and on and on... I took a complete ktrace of the startup and there are 24e6 NAMI events with the top files tested 2,000,000 times. I have thought of placing symlinks in the folder(s) where it first looks for any given file, to make sure it finds the file... but this does not seem quite right either. It's definitely a hack. I tried something like this and it didn't help much. The code still wants to open libraries multiple times. I've been looking at adding caching to lt_dlopenext() and my first attempt went much faster but blew up because I wasn't correctly handling open/close/open sequences (libm is opened and then closed 42,000 times). I think this is the way forward but need to find the time to understand ltdl.[ch] (~4800 lines). What I'm wondering is what is the lists opinion on how to best fix this type of a problem. Is this even the cause of my long startup? Any system calls involving opening pathnames are expensive, even with the namei cache. Having 4 orders of magnitude too many is a destinct problem. I have spoken with one or two of the gnucash devs, they seem to think this is unique to FreeBSD, meaning they have not seen this problem on any other platform. They said it might have to do with how FreeBSD handles how files are opened up many times recursively!? Possibly Linux can more efficiently handle opening a non-existent file but the underlying problem is that there are far too many system calls being executed during the gnucash startup. It would be interesting to get a truss of gnuash starting on another OS (unfortunately, I don't have access to any Linux systems) and/or some other guile applications. FWIW: I spoke with some folks on a gnucash channel. They ran a trace for me on gnucash, and it only attempted to load files 17 times or so. Each time it loaded a file it hung onto it. Sounds like the 'close' is not releasing the library like it does on fbsd. Which is how it 'should' work. If there is a more appropriate list, please let me know. -ports may be better. -- Regards, Eric ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: repeatedly opening the same .so(s) is slow?
[EMAIL PROTECTED] wrote: On Mon, Mar 20, 2006 at 10:49:57AM -0600, Eric Schuele wrote: I have a port (gnucash) which takes 3-4 minutes to open on a 2.6GHz machine. It used to take 15-20 seconds till all of the libtool changes. This sounds exactly like the problems I initially had with KDE on DragonFly. You say 'initially'. Did you find a fix? Check whether it is using libtool's dlopen wrapper, since it It has its own libguile-ltdl.so. I'm not sure of its function though as it can happily be replaced with the ligltdl.so, with no immediate bad side effects. seems to believe that the system dlopen either can't support hard-coded search paths (known bug in the last 1.5 version of libtool) or can't trace dependency libs. Joerg ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED] -- Regards, Eric ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
DRM kernel module for unichrome ?
Hi everybody, I am trying to get DRI to work on a VIA C3 motherboard. Background: running mplayer freezes X. (just X, I can ssh and reboot the box) Running mplayer -vo x11 (instead of the default that uses Xv extension) works, but uses much CPU. I understand that for Xv, XVmc to work, DRI must be enabled. However, although the port graphics/dri includes a unichrome_dri.so, I do not see the corresponding drm kernel module in /boot/loader. (I would assume it would be unichrome.ko) The question is then, is anybody working on this module ? How hard is it to port the linux one over to FreeBSD ? Who owns the current drm kernel modules and how can I assist in porting the unichrome drm module ? bruno ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: patchset-9 release (Re: [unionfs][patch] improvements of the unionfs - Problem Report, kern/91010)
Jacques Marneweck ha scritto: Danny Braniss wrote: Daichi GOTO wrote: All folks have interests in improved unionfs should keep attentions and ask how about merge? at every turn :) OK. How about a merge? I'd really like to see this in 6-STABLE. Regards, Jan Mikkelsen. just a 'me too'. I've been running with the patch(under 6.1) and it's definitely better than the panics with the unpatched version. in other words, IMHO, it does not break anything, and it actualy fixes somethings. danny Any ETA to when we can see this merged into 6.1 and 5.5? This patchset doesn't apply in 5.x branch. The unionfs code of 5.x is different and afaik is working quite well (we used it on freesbie 1.1 without problems). Cheers, -- Dario Freni ([EMAIL PROTECTED]) FreeSBIE developer (http://www.freesbie.org) GPG Public key at http://www.saturnero.net/saturnero.asc signature.asc Description: OpenPGP digital signature
Re: repeatedly opening the same .so(s) is slow?
On Mon, 2006-Mar-20 13:06:28 -0600, Eric Schuele wrote: FWIW... I have removed my symlink to libguile-ltdl.so and recreated it to point at libltdl.so.1. So that guile is using my stock libltdl.so. I get the same results. And gnucash seems to run fine. My reading of the code says that this will be missing the scheme-specific ltdl hooks so loading a shared library from guile should fail. being executed during the gnucash startup. It would be interesting to get a truss of gnuash starting on another OS (unfortunately, I don't have access to any Linux systems) and/or some other guile applications. hmm... I have a Gentoo system somewhere. It was just an experiment. No idea what shape its in. But maybe I can try installing gnucash on it. I had a try at building gnucash on a Solaris system today but ran into portability problems - Guppi includes gcc extensions (I was using Forte), one of the bits of gnome didn't include gettext correctly (so it wouldn't link) and something (I don't remember what) assumes that glade is installed but doesn't check for it in the configure stage. -- Peter Jeremy ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
