Re: On cooperative work [Was: Re: newbus' ivar's limitation..]
On Wed, Aug 1, 2012 at 1:05 PM, Arnaud Lacombe lacom...@gmail.com wrote: Hi, On Wed, Aug 1, 2012 at 12:40 PM, Attilio Rao atti...@freebsd.org wrote: On Wed, Aug 1, 2012 at 5:32 PM, Arnaud Lacombe lacom...@gmail.com wrote: Hi, On Tue, Jul 31, 2012 at 4:14 PM, Attilio Rao atti...@freebsd.org wrote: You don't want to work cooperatively. Why is it that mbuf's refactoring consultation is being held in internal, private, committers-and-invite-only-restricted meeting at BSDCan ? Why is it that so much review and discussion on changes are held privately ? Arnaud, belive me, to date I don't recall a single major technical decision that has been settled exclusively in private (not subjected to peer review) and in particular in person (e-mail help you focus on a lot of different details that you may not have under control when talking to people, etc). Whose call is it to declare something worth public discussion ? No one. Every time I see a Suggested by:, Submitted by:, Reported by:, and especially Approved by:, there should to be a public reference of the mentioned communication. Sometimes it is useful that a limited number of developers is involved in initial brainstorming of some works, Never. but after this period constructive people usually ask for peer review publishing their plans on the mailing lists or other media. Again, never. By doing so, you merely put the community in a situation where, well, We, committers, have come with this, you can either accept or STFU, but no major changes will be made because we decided so. The callout-ng conference at BSDCan was just beautiful, it was basically: Speaker: we will do this Audience: how about this situation ? What you will do will not work. Speaker: thank you for listening, end of the conference It was beautiful to witness. If you don't see any public further discussion this may be meaning: a) the BSDCan meetings have been fruitless and there is no precise plan/roadmap/etc. so not only you make it private, but it shamelessly failed... b) there is still not consensus on details Then the discussion should stop, public records are kept for reference in the future. There is no problem with this. and you can always publically asked on what was decided and what not. Just send a mail to interested recipients and CC any FreeBSD mailing list. This is not the way openness should be about. I attended the developer summit, and attended the mbuf working group ... I'm also not a committer. My ASCII transcription of the results of the white-board session were posted to freebsd-arch in june, the post is available for viewing here: http://lists.freebsd.org/pipermail/freebsd-arch/2012-June/012629.html When the information is readily available (as it is in this case), there is a clear case of confusing one's inability to engage the entirety of FreeBSD with openness. If you are concerned about the mbuf decisions, you should be subscribed to (and reading) the arch list. - Arnaud Attilio -- Peace can only be achieved by understanding - A. Einstein ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org -- regards, matt ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Status of BSD Diff replacement?
On Apr 21, 2012 4:15 PM, Ben Fiedler bfied...@asu.edu wrote: http://www.public.asu.edu/~bfiedler/bsdtextproc.tar.gz Here's a tar.gz of my project file: I did not include the diff/ directory, but instead gabor_diff/ , as that's where the latest changes are. iirc the original diff/ in my project was taken from the source for Gabor's 'bsdiff' under the ports tree, but then after a few weeks I discovered he had made newer changes to the code under perforce, so I based gabor_diff/ off of that. Sorry if this is all confusing :) -Ben Thanks a lot Ben. On Tue, Apr 17, 2012 at 8:30 PM, Matthew Story matthewst...@gmail.com wrote: On Tue, Apr 17, 2012 at 10:01 PM, Ben Fiedler bfied...@asu.edu wrote: Gabor, I made a branch off of your perforce diff code in my work on the diff tool: From my understanding you started those modifications from OpenBSD's diff in 2008, so Matthew's assertion that our incomplete BSD diff is OpenBSD diff + improvements is 100% correct. I also ported and started work on sdiff and diff3 from OpenBSD, but made minimal headway on each. The red items on the table here lists the needed argument support to match GNU grep: http://wiki.freebsd.org/SOC2010BenFiedler#diff Awesome, thanks for that link. Though there's only a few left, they are not trivial by any means. -Ben On Tue, Apr 17, 2012 at 4:48 PM, Gabor Kovesdan ga...@freebsd.org wrote: On 2012.04.17. 23:03, Matthew Story wrote: Just wondering what the current status is on a BSD diff replacement. The IdeasPage suggests that a goodly amount of work was done on this for GSoC 2010 ( http://wiki.freebsd.org/IdeasPage#BSD-licensed_Text-Processing_Tools), but the GPLinBase page says it's unowned and suggests replacement with OpenBSD diff (http://wiki.freebsd.org/GPLinBase). Unless OpenBSD folks have changed or developed something, our incomplete BSD diff is OpenBSD diff + improvements. Wondering how much is outstanding on this, and where to start reading to catch up on what's been done? I worked a bit on that in 2008 along with grep and sort but these got more priorities so lots of features are still missing. Then Ben Fiedler also worked on it in 2010 but I don't exactly know what he accomplished and whether he took my code or chose another way. So for someone who wants to work on it, first it should be checked what's done, maybe merge my version and Ben's version, just to verify, these are the correct 2 branches to look at: http://p4web.freebsd.org/@md=dcd=//depot/projects/soc2008/c=iZC@//depot/projects/soc2008/gabor_textproc/?ac=83 http://p4web.freebsd.org/@md=dcd=//depot/projects/soc2010/c=QTP@//depot/projects/soc2010/bsdtextproc/?ac=83 it looks like gabor_diff in soc2010 is based off the soc2008 work. Is there anyway either of you could provide me with an archive of the working tree for these 2 perforce repos? or make it available in a branch on svn.freebsd.org? I'd like to look into this more, but after reading through the P4Web docs, trying to gain anonymous read-only access through p4 itself, and then reading: http://lists.freebsd.org/pipermail/freebsd-questions/2007-August/156862.html it seems there's no real way to accommodate this sort of thing at current. check whether OpenBSD added something new or fixed somethings and then implement missing features and do lots of testing to ensure compatibility with GNU diff. And performance tests and improvements if necessary. Since 2008/2010 the OpenBSD change logs referencing diff(1) sdiff(1) and diff(3) are: 4.9 Use scandir(3) instead of getdirentries(2) in diff(1). Call to getdirentries(2) should be avoided outside of libc 4.8 Many diff(1) improvements. Make diff(1) return 2 on error. 4.6 Fix file descriptor leaks in sdiff(1) when diffing regular files. I think the many diff(1) improvements is when ray started maintaining diff (not millert), so perhaps I can ping him as well if I make any headway on this. I work on grep/regex related things and recently Oleg Moskalenko took over my incomplete BSD sort code but noone is working on BSD diff so any contribution is very welcome. Gabor -- regards, matt ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Status of BSD Diff replacement?
Just wondering what the current status is on a BSD diff replacement. The IdeasPage suggests that a goodly amount of work was done on this for GSoC 2010 (http://wiki.freebsd.org/IdeasPage#BSD-licensed_Text-Processing_Tools), but the GPLinBase page says it's unowned and suggests replacement with OpenBSD diff (http://wiki.freebsd.org/GPLinBase). Wondering how much is outstanding on this, and where to start reading to catch up on what's been done? -- regards, matt ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Status of BSD Diff replacement?
On Tue, Apr 17, 2012 at 10:01 PM, Ben Fiedler bfied...@asu.edu wrote: Gabor, I made a branch off of your perforce diff code in my work on the diff tool: From my understanding you started those modifications from OpenBSD's diff in 2008, so Matthew's assertion that our incomplete BSD diff is OpenBSD diff + improvements is 100% correct. I also ported and started work on sdiff and diff3 from OpenBSD, but made minimal headway on each. The red items on the table here lists the needed argument support to match GNU grep: http://wiki.freebsd.org/SOC2010BenFiedler#diff Awesome, thanks for that link. Though there's only a few left, they are not trivial by any means. -Ben On Tue, Apr 17, 2012 at 4:48 PM, Gabor Kovesdan ga...@freebsd.org wrote: On 2012.04.17. 23:03, Matthew Story wrote: Just wondering what the current status is on a BSD diff replacement. The IdeasPage suggests that a goodly amount of work was done on this for GSoC 2010 (http://wiki.freebsd.org/**IdeasPage#BSD-licensed_Text-** Processing_Toolshttp://wiki.freebsd.org/IdeasPage#BSD-licensed_Text-Processing_Tools), but the GPLinBase page says it's unowned and suggests replacement with OpenBSD diff (http://wiki.freebsd.org/**GPLinBasehttp://wiki.freebsd.org/GPLinBase ). Unless OpenBSD folks have changed or developed something, our incomplete BSD diff is OpenBSD diff + improvements. Wondering how much is outstanding on this, and where to start reading to catch up on what's been done? I worked a bit on that in 2008 along with grep and sort but these got more priorities so lots of features are still missing. Then Ben Fiedler also worked on it in 2010 but I don't exactly know what he accomplished and whether he took my code or chose another way. So for someone who wants to work on it, first it should be checked what's done, maybe merge my version and Ben's version, just to verify, these are the correct 2 branches to look at: http://p4web.freebsd.org/@md=dcd=//depot/projects/soc2008/c=iZC@//depot/projects/soc2008/gabor_textproc/?ac=83 http://p4web.freebsd.org/@md=dcd=//depot/projects/soc2010/c=QTP@//depot/projects/soc2010/bsdtextproc/?ac=83 it looks like gabor_diff in soc2010 is based off the soc2008 work. Is there anyway either of you could provide me with an archive of the working tree for these 2 perforce repos? or make it available in a branch on svn.freebsd.org? I'd like to look into this more, but after reading through the P4Web docs, trying to gain anonymous read-only access through p4 itself, and then reading: http://lists.freebsd.org/pipermail/freebsd-questions/2007-August/156862.html it seems there's no real way to accommodate this sort of thing at current. check whether OpenBSD added something new or fixed somethings and then implement missing features and do lots of testing to ensure compatibility with GNU diff. And performance tests and improvements if necessary. Since 2008/2010 the OpenBSD change logs referencing diff(1) sdiff(1) and diff(3) are: 4.9 Use scandir(3) instead of getdirentries(2) in diff(1). Call to getdirentries(2) should be avoided outside of libc 4.8 Many diff(1) improvements. Make diff(1) return 2 on error. 4.6 Fix file descriptor leaks in sdiff(1) when diffing regular files. I think the many diff(1) improvements is when ray started maintaining diff (not millert), so perhaps I can ping him as well if I make any headway on this. I work on grep/regex related things and recently Oleg Moskalenko took over my incomplete BSD sort code but noone is working on BSD diff so any contribution is very welcome. Gabor -- regards, matt ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
FTSENT: name and path on `/' versus name and path on `*/'
Found a curious incongruent behavior in fts(3), wondering if there is some reason for this, or if it's just a bug. If you include the path `/' the FTSENT at depth 0 that is returned for the path has both fts_path = / and fts_name = /, compared to other entries, like /var which has fts_path = / and fts_path = / and fts_name = var, or /var/, which has fts_path = /var/ and fts_name = . Given the behavior of other paths used in fts(3), my expectation here is that FTSENT for path / on depth 0 would have fts_path = / and fts_name = . Haven't delved down into the code enough to figure out where this is happening, but from a cursory read through libc/gen/fts.c there doesn't seem to be any explicit special casing of the path /. Can anyone shed light on why this behavior is desirable, or if it's just a bug I'm happy to file a PR and delve further into fts.c ... -- regards, matt ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: xargs short-circuit
On Tue, Feb 14, 2012 at 3:25 PM, Matthew Story matthewst...@gmail.comwrote: On Tue, Feb 14, 2012 at 2:37 PM, Matthew Story matthewst...@gmail.comwrote: On Tue, Feb 14, 2012 at 2:35 PM, Jilles Tjoelker jil...@stack.nl wrote: On Tue, Feb 14, 2012 at 01:34:49PM -0500, Matthew Story wrote: After reading the man-page, and browsing around the internet for a minute, I was just wondering if there is an option in (any) xargs to short-circuit on first failure of [utility [arguments]]. e.g. $ jot - 1 10 | xargs -e -n1 sh -c 'echo $*; echo exit 1' worker || echo $? 1 1 such that any non-0 exit code in a child process would cause xargs to stop processing. seems like this would be a nice feature to have. As per xargs(1), you can do this by having the command exit on a signal or with a value of 255. exit 255 with -P, and SIGTERM (with or without -P) causes FreeBSD xargs to orphan, is this desirable behavior? findutils xargs orphans on 255 and SIGTERM (with -P), but does not orphan without -P when SIGTERM is sent. I would expect xargs to propegate the signal, or wait, although the man page does say immediately, the POSIX specification is less clear ... this makes it more-or-less unsuitable for my needs, but i guess i could do something like: ... | xargs sh -c '... exit 255;' if [ $? -ne 0 ]; then wait # cleanup exit 1 fi I have patched xargs behavior on exit 255 from utility, or termination of utility via signal to wait on existing utility processes before exiting 1. This make the exit 255 behavior much more predictable. I sent a lengthier explanation of the patch and reasoning to arch@, but figured I would follow up in thread as well. Patch available here: http://axe0.blackskyresearch.net/patches/matt/xargs.no_orphan.patch.txt Hoping this patch will make it back into xargs, it makes exit 255 predictable with -P 1. Yes indeed it does ... should have scoured further, thanks! -- Jilles Tjoelker -- regards, matt -- regards, matt -- regards, matt ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
xargs short-circuit
After reading the man-page, and browsing around the internet for a minute, I was just wondering if there is an option in (any) xargs to short-circuit on first failure of [utility [arguments]]. e.g. $ jot - 1 10 | xargs -e -n1 sh -c 'echo $*; echo exit 1' worker || echo $? 1 1 such that any non-0 exit code in a child process would cause xargs to stop processing. seems like this would be a nice feature to have. -- regards, matt ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: xargs short-circuit
On Tue, Feb 14, 2012 at 1:34 PM, Matthew Story matthewst...@gmail.comwrote: After reading the man-page, and browsing around the internet for a minute, I was just wondering if there is an option in (any) xargs to short-circuit on first failure of [utility [arguments]]. e.g. $ jot - 1 10 | xargs -e -n1 sh -c 'echo $; exit 1' worker || echo $? # cp error on my part, should not read echo exit 1, just exit 1 1 1 such that any non-0 exit code in a child process would cause xargs to stop processing. seems like this would be a nice feature to have. apologies for the copy-paste error. -- regards, matt ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: xargs short-circuit
On Tue, Feb 14, 2012 at 2:05 PM, Devin Teske devin.te...@fisglobal.comwrote: -Original Message- From: owner-freebsd-hack...@freebsd.org [mailto:owner-freebsd- hack...@freebsd.org] On Behalf Of Matthew Story Sent: Tuesday, February 14, 2012 10:35 AM To: freebsd-hackers@freebsd.org Subject: xargs short-circuit After reading the man-page, and browsing around the internet for a minute, I was just wondering if there is an option in (any) xargs to short-circuit on first failure of [utility [arguments]]. e.g. $ jot - 1 10 | xargs -e -n1 sh -c 'echo $*; echo exit 1' worker || echo $? 1 1 such that any non-0 exit code in a child process would cause xargs to stop processing. seems like this would be a nice feature to have. You can achieve this quite easily with a sub-shell: As a bourne-shell script: #!/bin/sh jot - 1 10 | ( while read ARG1 REST; do sh -c 'echo $*; exit 1' worker $ARG1 || exit $? shift 1 done ) read is often not sufficient for a variety of reasons, the most notable of them is that new-lines are valid in file names on most file systems. While some shells do support a variety of options, POSIX only supports -r (raw, treat backslashes as literal, not escape). find . -print0 | xargs -0 -e ... Is vastly nicer in most cases. Additionally, xargs provides the possibility of concurrency, via -P ... while you can spoof this with trailing and wait(1) in sh, this is both vastly more complicated than xargs -P, and not as efficient in spawning jobs, it would be nice to be able to have xargs stop spawning new jobs on first failure in this case, and exit at last reap of existing child processes if the short-circuit flag is sent: find . -print0 | xargs -n1 -0 -e -P4 ... My use-case is a CPU-bound operation running with concurrency and many more jobs than concurrency, on failure xargs continues to work until finished to report failure, which is a large number of wasted cycles, and box load. Would be nice to bail as early as possible in situations where any failure is fatal to the larger operation. Or interactively in sh/bash: $ jot - 1 10 | ( while read ARG1 REST; do sh -c 'echo $*; exit 1' worker $ARG1 || exit $?; shift 1;done ) Or interactively in csh/tcsh: % jot - 1 10 | /bin/sh -c 'while read ARG1 REST; do sh -c '\''echo $*; exit 1'\'' worker $ARG1 || exit $?; shift 1; done' -- Devin _ The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you. -- regards, matt ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: xargs short-circuit
On Tue, Feb 14, 2012 at 2:35 PM, Jilles Tjoelker jil...@stack.nl wrote: On Tue, Feb 14, 2012 at 01:34:49PM -0500, Matthew Story wrote: After reading the man-page, and browsing around the internet for a minute, I was just wondering if there is an option in (any) xargs to short-circuit on first failure of [utility [arguments]]. e.g. $ jot - 1 10 | xargs -e -n1 sh -c 'echo $*; echo exit 1' worker || echo $? 1 1 such that any non-0 exit code in a child process would cause xargs to stop processing. seems like this would be a nice feature to have. As per xargs(1), you can do this by having the command exit on a signal or with a value of 255. Yes indeed it does ... should have scoured further, thanks! -- Jilles Tjoelker -- regards, matt ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: xargs short-circuit
On Tue, Feb 14, 2012 at 2:37 PM, Matthew Story matthewst...@gmail.comwrote: On Tue, Feb 14, 2012 at 2:35 PM, Jilles Tjoelker jil...@stack.nl wrote: On Tue, Feb 14, 2012 at 01:34:49PM -0500, Matthew Story wrote: After reading the man-page, and browsing around the internet for a minute, I was just wondering if there is an option in (any) xargs to short-circuit on first failure of [utility [arguments]]. e.g. $ jot - 1 10 | xargs -e -n1 sh -c 'echo $*; echo exit 1' worker || echo $? 1 1 such that any non-0 exit code in a child process would cause xargs to stop processing. seems like this would be a nice feature to have. As per xargs(1), you can do this by having the command exit on a signal or with a value of 255. exit 255 with -P, and SIGTERM (with or without -P) causes FreeBSD xargs to orphan, is this desirable behavior? findutils xargs orphans on 255 and SIGTERM (with -P), but does not orphan without -P when SIGTERM is sent. I would expect xargs to propegate the signal, or wait, although the man page does say immediately, the POSIX specification is less clear ... this makes it more-or-less unsuitable for my needs, but i guess i could do something like: ... | xargs sh -c '... exit 255;' if [ $? -ne 0 ]; then wait # cleanup exit 1 fi Yes indeed it does ... should have scoured further, thanks! -- Jilles Tjoelker -- regards, matt -- regards, matt ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: intent of tab-completion in /bin/sh in 9.0
forgot to reply-to list ... On Thu, Jan 19, 2012 at 8:23 AM, Matthew Story matthewst...@gmail.comwrote: On Wed, Jan 18, 2012 at 10:12 PM, Jason Hellenthal jh...@dataix.netwrote: [...snip] It would be nice if the completion made it down to 8.X. Agreed, on my 9.0 install, I have actually forgone my typical bash install, due mostly to the presence of tab completion, would be nice to remove bash from my 8.X systems as well. As for replacing roots shell (csh) I do not even see that as needed and a goal of mine to spend as little time as neccesary in root. Always a good role. The shell while I am in root never made a difference to me. Others may see differently. Was more-so just curious about the direction of this. I'm not a huge (t)csh fan, but understand there are historical reasons here ... not sure if historical reasons always justify continued support, but changing csh - sh for root (and removing toor) might be non-POLA for negligible benefit (as you suggest). -- ;s =; -- regards, matt -- regards, matt ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
intent of tab-completion in /bin/sh in 9.0
Just noticed that tab-completion in /bin/sh has been added in 9.0 (verified that it is not there in 8.0, dunno if it's there in 8.2, could probably go digging to figure it out). In addition to the command history via up:down (which is present in 8.0) FreeBSD sh is now actually a pretty usable interactive shell. I also noticed that the following bit has been removed from the sh(1): This version has many features which make it appear similar in some respects to the Korn shell, but it is not a Korn shell clone like pdksh. Just wondering if the general direction here is attempting to provide a minimal POSIX shell, that is useful enough interactively to become the default root shell (supplanting csh)? Or if there is just a general trend towards adopting more of the ksh feature-set. Relatively new to list, so if this has been discussed, apologies. -- regards, matt ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: intent of tab-completion in /bin/sh in 9.0
On Wed, Jan 18, 2012 at 5:16 PM, Jilles Tjoelker jil...@stack.nl wrote: [...snip] On the contrary, our /bin/sh is minimalistic compared to many other shells used in that role, like bash, pdksh, mksh and ksh93. It (the 9.0 version) has only slightly more features than dash or NetBSD's sh, and dash has instead some other features. I prefer FreeBSD sh over these others for its minimalism (although I do like dash as well), particularly when not being used interactively. [...snip] POSIX itself has gradually adopted ksh features, so seeing more of them in future is not unlikely. Most of the new language features in 9.0 are either from POSIX.1-2008 or on the roadmap for a new version of POSIX (in collaboration with other shell authors). Tab completion is a welcome addition, I was unaware that this had been (or is slated to be) added to the POSIX specification. This makes far more sense than my proposed explanations. Thanks for the clarification. Some plans for sh in 10.0 are in this mailing list post: http://lists.freebsd.org/pipermail/freebsd-arch/2011-December/011976.html Let me know what (if anything) I can do anything to help with the continued development of sh, cheers. -- Jilles Tjoelker -- regards, matt ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
