Date: Wed, 27 Nov 1996 08:14:28 -0500 From: Lotus_Mail_Exchange@CSERVE4.CCMAIL.compuserve.com To: "INTERNET:hackers@freefall.freebsd.org" <hackers@freefall.freebsd.org> Subject: NON-DELIVERY of: hackers-digest V1 #1667 Message-ID: <199611270815_MC1-BC4-D910@compuserve.com>
next in thread | raw e-mail | index | archive | help
Sender: owner-hackers-digest@freefall.freebsd.org
Received: from smyrno.sol.net (smyrno.sol.net [206.55.64.117]) by hil-img-3.compuserve.com (8.6.10/5.950515)
id VAA18199; Thu, 21 Nov 1996 21:21:28 -0500
From: <owner-hackers-digest@freefall.freebsd.org>
Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.18]) by smyrno.sol.net (8.8.3/8.8.3) with ESMTP id TAA02856; Thu, 21 Nov 1996 19:54:47 -0600 (CST)
Received: (from root@localhost)
by freefall.freebsd.org (8.7.5/8.7.3) id RAA03743
for freebsd-hackers-digest-outgoing; Thu, 21 Nov 1996 17:29:03 -0800 (PST)
Date: Thu, 21 Nov 1996 17:29:03 -0800 (PST)
Message-Id: <199611220129.RAA03743@freefall.freebsd.org>
To: freebsd-hackers-digest@FreeBSD.ORG
Subject: hackers-digest V1 #1667
Reply-To: hackers@freefall.freebsd.org
Errors-To: owner-hackers-digest@freefall.freebsd.org
Precedence: bulk
hackers-digest Thursday, 21 November 1996 Volume 01 : Number 1667
In this issue:
Re: the way things are going (Was: Who needs Perl?)
WCARCHIVE DOWN AGAIN.
Re: Who needs Perl? We do!
Re: panic: ffs_valloc: dup alloc
Re: New mailing list - CVS-Alert???
Re: Who needs Perl? We do!
Re: Who needs Perl? We do!
Re: Who needs Perl? We do!
Re: Who needs Perl? We do!
Re: Who needs Perl? We do!
Re: Who needs Perl? We do!
Re: Disk Striping
Re: Who needs Perl? We do!
Re: Who needs Perl? We do!
Re: Who needs Perl? We do!
----------------------------------------------------------------------
From: J Wunsch <j@uriah.heep.sax.de>
Date: Fri, 22 Nov 1996 00:23:57 +0100 (MET)
Subject: Re: the way things are going (Was: Who needs Perl?)
As Nate Williams wrote:
[Excellent explanation deleted, i fully agree with Nate here.]
> That's how things work around here. You don't get 'blessings' or
> 'permission' to do something, you do it and then find an advocate to run
> with it. After the advocate is happy with your work (or too overloaded
> to do it himself), you become a committer and then are one of the
> 'blessed/cursed' who are responsible for the whole darn mess.
Well, but you forgot: that's exactly the point where the real work
begins... ;-)
- --
cheers, J"org
joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE
Never trust an operating system you don't have sources for. ;-)
------------------------------
From: Eric Tremblay <eric@cdrom.com>
Date: Thu, 21 Nov 96 16:21:45 -0800
Subject: WCARCHIVE DOWN AGAIN.
CRL called again, WCARCHIVE is down again. 4:21 for the past 30 minutes.
Eric "E.T." Tremblay
Walnut Creek CDROM
eric@cdrom.com
------------------------------
From: Nate Williams <nate@mt.sri.com>
Date: Thu, 21 Nov 1996 17:34:44 -0700 (MST)
Subject: Re: Who needs Perl? We do!
[ Reduced the Cc list down. Please try and minimize the lists ]
> > Next point, people are jumping on Perl about how we have so few system
> > utils based on it it should go, where are the utils based on TCL?
>
> Wrong mentality. I have about 20,000 lines of Tcl here in out product
> which load a couple of custom libraries and talk to our hardware. This
> is what having Tcl in the tree is about, and is why I see Perl in the
> tree as a Very Good Thing.
But the policy is that nothing belongs in the 'src' tree unless
something else relies on it. You can get TCL via the ports (or could
have until we brought it into the tree) and it should have stayed there
since nothing still uses it and it's been over 5 months. I complained
when it was brought in and was told 'Real Soon Now', but nothing has
happened.
It's simply bloat that is useless to *most* users, and has no use in the
main tree. I'm willing to be proven wrong, but unless that happens soon
I'm gonna stay in the 'complain and moan' camp. (I *HATE* seeing stupid
TCL man-pages that come up instead of the C routines).
Nate
------------------------------
From: "Gary Palmer" <gpalmer@FreeBSD.ORG>
Date: Thu, 21 Nov 1996 19:33:26 -0500
Subject: Re: panic: ffs_valloc: dup alloc
Thomas David Rivers wrote in message ID
<199611161253.HAA26583@lakes.water.net>:
> > root@mail:/var/crash> gdb -k kernel vmcore.2
> > GDB is free software and you are welcome to distribute copies of it
> > under certain conditions; type "show copying" to see the conditions.
> > There is absolutely no warranty for GDB; type "show warranty" for details.
> > GDB 4.13 (i386-unknown-freebsd),
> > Copyright 1994 Free Software Foundation, Inc...
> > IdlePTD 1d5000
> > current pcb at 1abd64
> > panic: ffs_valloc: dup alloc
> > #0 boot (howto=260) at ../../i386/i386/machdep.c:912
> > 912 } else {
> > (kgdb) bt
> Welcome to the club :-)
> This is the panic that I have had for several months, which is
> duplicated almost every night.
Well, it just bit me again :-(
> Rest assured that several people are investigating this at this
> time...
> I believe it has something to do with the inode allocation bits in
> ffs_valloc(). Others believe some race conditions in vnode allocation
> are to blaim, etc... David Greene is investigating other avenues.
> It seems to me that we are closing in on the issue, if only by
> eliminating everything else :-)
Question:
it's always the same FS with me that bites the dust. Perhaps a
previous crash of the machine caused a FS corruption fsck isn't
picking up on. Has anyone who is being bothered by this dumped the fs
with *tar* (not dump) and resored to see if that fixes the problem?
Gary
- --
Gary Palmer FreeBSD Core Team Member
FreeBSD: Turning PC's into workstations. See http://www.FreeBSD.ORG/ for info
------------------------------
From: cracauer@wavehh.hanse.de (Martin Cracauer)
Date: Fri, 22 Nov 96 01:14:06 +0100
Subject: Re: New mailing list - CVS-Alert???
>I would like to propose a new mailing list. It would be called cvs-alert
>and wuold be for those times that someone makes a commit that requires
>either massive changes to way something is done or re-compiles
>of programs.
The sequence of actions to compile a kernel and then the world is
almost always the same (includes, config, kernel, compiler). I wrote
down some of it at (was for NetBSD, but applies to FreeBSD, too):
http://www.bik-gmbh.de/~cracauer/bsd-to-current.html
Besides getting a world to build, there's another issue: if you don't
do a make world everytime you have a new tree, how to find out what
programs need to be recompiled?
One example are tools that depend on kernel data structure layout. The
right thing to solve this is to make sure you rebuild such programs
when include files they reference changes. Traversing /usr/src/*bin*
that already has was compile at some time and an individual 'make
depend' should do the job.
Martin
- --
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
Martin Cracauer <cracauer@cons.org> http://cracauer.cons.org Fax +49405228536
"As far as I'm concerned, if something is so complicated that you can't ex-
plain it in 10 seconds, then it's probably not worth knowing anyway"- Calvin
------------------------------
From: Michael Smith <msmith@atrad.adelaide.edu.au>
Date: Fri, 22 Nov 1996 11:16:45 +1030 (CST)
Subject: Re: Who needs Perl? We do!
Nate Williams stands accused of saying:
>
> But the policy is that nothing belongs in the 'src' tree unless
> something else relies on it. You can get TCL via the ports (or could
This devolves to "nothing belongs in the source tree". If you accept
any other argument, then we are talking about what level of
service/redundancy (depending on perspective) is appropriate.
> main tree. I'm willing to be proven wrong, but unless that happens soon
> I'm gonna stay in the 'complain and moan' camp. (I *HATE* seeing stupid
> TCL man-pages that come up instead of the C routines).
And finally, your real gripe. How about reordering your manpage
search order so that 3 comes before n? I hate getting printf(1)
before printf(3) too; do you hear me griping about that?
> Nate
- --
]] Mike Smith, Software Engineer msmith@gsoft.com.au [[
]] Genesis Software genesis@gsoft.com.au [[
]] High-speed data acquisition and (GSM mobile) 0411-222-496 [[
]] realtime instrument control. (ph) +61-8-8267-3493 [[
]] Unix hardware collector. "Where are your PEZ?" The Tick [[
------------------------------
From: Terry Lambert <terry@lambert.org>
Date: Thu, 21 Nov 1996 17:34:57 -0700 (MST)
Subject: Re: Who needs Perl? We do!
> > There is too much "damage control" and too little "consideration" taking
> > place for an unbiased conclusion that what Richard volunteered to do
> > "wasn't what needed to be done".
>
> Richard was completely free to do what he wanted to do, but he wasn't
> going to get the 'blessing' of anyone until he had a working prototype
> that was at least as good as the current system.
I don't think that was the problem.
What he was looking for was a commitment that, if there was consensus
that the prototype was "at least as good as the current system", then
the existing system would be replaced.
In other words, a definition of an acceptable replacement and an
agreement to not change the definition out from under him while he
did the work.
Then all Richard would have to do is "meet spec" instead of "meet spec
and play politics".
> To bring in the blast from the past, you becamse the defacto patchkit
> maintainer because you did the work, not because you got Bill's (or
> anyone else for that matter) permission. I was given the ugly stick
> because (hopefully) I had shown to you my willingness to do the work and
> by organizing and doing work *before* you handed me the baton.
Not quite.
I agree that the results would have been the same, whatever the
motivation, if that's any consolation. 8-).
Actually, it was because I'm more interested in (figuratively) framing
houses than in nailing up sheetrock, spackling, and painting.
After building the machine for building patchkits, I was interested
in going on to build the next machine instead of running the one I
built. In other words, I wanted to do systems engineering, not patchkit
or release engineering.
If you want to go the the "blast from the past" immediately previous
to that one, I did the same thing with the FreeBSD FAQ: built a
tool, and then instead of using it, went on to the next tool (the
patchkit).
If I'd known then what I know now, I would have spent a bit more time
systems-engineering a template for volunteer organizations and a bit
less time waiting for Bill to wear the mantle designed by Linus. I
can only say that I was naieve about what the spirit of volunteerism
can and can't motivate in the face of normal human group dynamics
in the context of a private law system.
I'll know better The Next Time, and will install a self-maintaining,
machine-run voting democracy with a prioritization feedback loop.
Example:
Each person gets N "votes" in a time period, and can "spend" up to
0-K of them on any topic.
Each person also gets some M << N "call for votes" that they can "spend"
in a given time period. Majority rules.
Votes close 4 weeks after call, or when a majority is undeniable (the
number of remaining potential votes is less than the total minus the
votes already cast for one side of the issue).
Each accumulates over time, and both quit accumulating when they reach
the limit.
Same thing for organizational policy decisions, only with smaller limits
to ensure a longer periodic vector, and a 3/4 majority requirement. Like
vote accumulation period, initial votes for new members, expansion of
the comitters list, change in majority values, etc..
So if I truly feel strongly about something, I can "call for a vote",
and then "vote up to K votes" for/against.
Everyone else "votes up to K votes" for/against. If they care. If they
don't care enough to vote, then what they say really doesn't matter.
If I'm a whiner, I quickly run out of my number of "votes/call for votes"
and the activity is self-limiting. I'll either pace myself, or you
can "put me down" with opposing votes each time I enter a flurry of
activity.
If the main participants fail to participate fully, then the system
will self-correct to a different meta-stable state that excludes them,
but which does not penalize their future participation.
Goodbye to:
Subject: Re: Re: Re: Re: Re: My patch
I didn't have time to look at your patch, but I'll get to
it real soon now, I promise"
-- A member of the committer society
Subject: No time
Sorry, your changes are too large for us to be able to vet them.
-- A member of the code vetting society
Subject: Re: Closed developement
Sorry, I just don't have time to waste on organizational
issues, I'm busy coding!
-- A member of the organization committe
Ah, ode to fuzzy control systems!
Regards,
Terry Lambert
terry@lambert.org
- ---
Any opinions in this posting are my own and not those of my present
or previous employers.
------------------------------
From: Nate Williams <nate@mt.sri.com>
Date: Thu, 21 Nov 1996 17:51:31 -0700 (MST)
Subject: Re: Who needs Perl? We do!
> > But the policy is that nothing belongs in the 'src' tree unless
> > something else relies on it. You can get TCL via the ports (or could
>
> This devolves to "nothing belongs in the source tree". If you accept
> any other argument, then we are talking about what level of
> service/redundancy (depending on perspective) is appropriate.
Everything in the tree has a purpose. I can't do *anything* with TCL,
and nothing in the tree uses TCL. I need the compiler to rebuild
myself, but I don't need TCL for *anything* (w/regards to the system).
TCL alone doesn't provide anything, while ls does (it's part of the OS).
I'd even throw the games out, but they are considered part of 'standard
BSD' releases.
> > main tree. I'm willing to be proven wrong, but unless that happens soon
> > I'm gonna stay in the 'complain and moan' camp. (I *HATE* seeing stupid
> > TCL man-pages that come up instead of the C routines).
>
> And finally, your real gripe.
No, that was a 'PLUS, I also hate it' kind of gripe.
Nate
------------------------------
From: Michael Smith <msmith@atrad.adelaide.edu.au>
Date: Fri, 22 Nov 1996 11:31:32 +1030 (CST)
Subject: Re: Who needs Perl? We do!
Nate Williams stands accused of saying:
> >
> > This devolves to "nothing belongs in the source tree". If you accept
> > any other argument, then we are talking about what level of
> > service/redundancy (depending on perspective) is appropriate.
>
> Everything in the tree has a purpose. I can't do *anything* with TCL,
> and nothing in the tree uses TCL. I need the compiler to rebuild
> myself, but I don't need TCL for *anything* (w/regards to the system).
*You* may not be able to do anything with Tcl, but *I* can. *I*
can't do anythying with Perl, but *other* people can. Nobody uses
the entire feature set of the system; that is a given.
> TCL alone doesn't provide anything, while ls does (it's part of the OS).
Tcl is actually used for BMaking stuff, as you may have noticed.
Jordan is bolting the new install together using it. I'm working on
some configuration tools using it.
'ls' is only useful if you are a shell user, and need to see what
files are on the disk. There are plenty of systems where 'ls' isn't
particularly useful at all. Like I said, we're talking about a matter
of degree, not principle.
> No, that was a 'PLUS, I also hate it' kind of gripe.
Hmm, it was the only one I could see that wasn't purely philosophical.
> Nate
- --
]] Mike Smith, Software Engineer msmith@gsoft.com.au [[
]] Genesis Software genesis@gsoft.com.au [[
]] High-speed data acquisition and (GSM mobile) 0411-222-496 [[
]] realtime instrument control. (ph) +61-8-8267-3493 [[
]] Unix hardware collector. "Where are your PEZ?" The Tick [[
------------------------------
From: Nate Williams <nate@mt.sri.com>
Date: Thu, 21 Nov 1996 17:58:17 -0700 (MST)
Subject: Re: Who needs Perl? We do!
> > > There is too much "damage control" and too little "consideration" taking
> > > place for an unbiased conclusion that what Richard volunteered to do
> > > "wasn't what needed to be done".
> >
> > Richard was completely free to do what he wanted to do, but he wasn't
> > going to get the 'blessing' of anyone until he had a working prototype
> > that was at least as good as the current system.
>
> I don't think that was the problem.
That was *the* problem, and I was one of the most prolific posters.
> What he was looking for was a commitment that, if there was consensus
> that the prototype was "at least as good as the current system", then
> the existing system would be replaced.
You get that *after* you've proven your point, not before. That's the
way things work. Because one person's 'solution' may meet all the
technical criteria (ie; it solves the problem) doesn't mean it meets all
the criteria (is this *better* than the current system).
I won't buy off on *anything* simply because there is no such thing as
'completely technical' solution that have no politics/emotions/personal
judgement involved.
Richard may think he solution is 'easier/better/cleaner', but since I'm
one of the users responsible for using it I leave it up to *MY*
judgement to determine that. If he doesn't like my opinion, he can
bring it up with someone else, etc...
As a 'committer' I'm responsible for the code in the tree, and
responsible to both users and developers. I don't take that
responsibility lightly, and as such you should be commending the
committers for trying to maintain some semblance of 'consistancy' in the
tree rather than beating them over the head for doing their job.
Nate
------------------------------
From: Nate Williams <nate@mt.sri.com>
Date: Thu, 21 Nov 1996 18:07:08 -0700 (MST)
Subject: Re: Who needs Perl? We do!
Michael Smith writes:
> Nate Williams stands accused of saying:
> > >
> > > This devolves to "nothing belongs in the source tree". If you accept
> > > any other argument, then we are talking about what level of
> > > service/redundancy (depending on perspective) is appropriate.
> >
> > Everything in the tree has a purpose. I can't do *anything* with TCL,
> > and nothing in the tree uses TCL. I need the compiler to rebuild
> > myself, but I don't need TCL for *anything* (w/regards to the system).
>
> *You* may not be able to do anything with Tcl, but *I* can. *I*
> can't do anythying with Perl, but *other* people can. Nobody uses
> the entire feature set of the system; that is a given.
>
> > TCL alone doesn't provide anything, while ls does (it's part of the OS).
>
> Tcl is actually used for BMaking stuff, as you may have noticed.
> Jordan is bolting the new install together using it. I'm working on
> some configuration tools using it.
Let's see those tools, and then I'll shutup. Again, there are lots of
*useful* things that we could bring in, but they aren't used and/or
essential. Should we bring in Python as well, and what about the new
Limbo compiler from the folks at Lucent (nee Bell Labs). What about the
ADA compiler from the GNU folks? Where do you draw the line between
'useful to some' and 'bloat'.
It was decided a *LONG* time ago that unless a utility was part of the
standard BSD distribution and/or was required for the running system it
shouldn't be part of the tree.
'libforms' was recently deleted since it was a 'good idea' that never
came to pass. It might have been a useful tool, but *FreeBSD* doesn't
use it.
> 'ls' is only useful if you are a shell user, and need to see what
> files are on the disk. There are plenty of systems where 'ls' isn't
> particularly useful at all. Like I said, we're talking about a matter
> of degree, not principle.
FreeBSD is sold as a multi-user Unix system. 'ls' is required on that,
and as well it's distributed as part of the 'standard BSD' tools.
Nate
------------------------------
From: michael butler <imb@scgt.oz.au>
Date: Fri, 22 Nov 1996 12:08:09 +1100 (EST)
Subject: Re: Disk Striping
Jaye Mathisen writes:
> Uh, by definition, isn't striping spreading the load across spindles?
> I realize it's a tad more complicated than that, but the essence is the
> same.
This is optimally effective when there is only one locality of reference
since striping then serves to reduce the number of seeks (divide number of
tracks transferred by N drives) and introduce an element of parallelism into
the disk transactions (each drive will detach from the SCSI bus whilst busy).
> > There are four activities which consume disk resources:
> >
> > i) maintenance of the active and history files
> > ii) maintenance of the overview hierarchy
> > iii) writing out the articles themselves
> > iv) scribbling to /var/log/news
These activities are usually not operating on adjacent locales when
implemented on a single drive (or one logical constructed out of a few
physical ones). Thus the striped drive will be seeking all over the place
and losing much of the advantage of striping in the first place. You do not
want to design something that inherently seeks a lot, you need to minimise
seeking for both performance, long term reliability and drive life.
It is, however, quite valid to stripe any one activity, such as scribbling
out the articles across multiple drives. You could, for example, use two
striped drives for the history stuff, one for the overview (only if you have
any readers) and two striped for the article spool to achieve what you're
after. Even better, split the two striped arrangements onto two separate
(SCSI) controllers,
michael
------------------------------
From: davidn@sdev.usn.blaze.net.au (David Nugent)
Date: Fri, 22 Nov 1996 12:12:44 +1100
Subject: Re: Who needs Perl? We do!
Michael Smith writes:
> > This is a different argument entirely... it is a complaint that the
> > installation dependency process is insufficiently seamless.
>
> No it is _not_. Any statically-configured system is vulnerable to
> variation in usage pattern; the simple intent here is to cover more of
> the possible requirements in the out-of-the-box configuration in a
> reasonable fashion.
If this is the reason for having it, then Perl4 is no longer
viable. In the real world, the only requirement it meets is
being able to run the scripts with which FreeBSD is delivered,
and that is far too minimal to handle "possible requirements"
for using perl scripts from elsewhere, most of which are now
require perl5.
It needs to be removed or replaced.
David Nugent, Unique Computing Pty Ltd - Melbourne, Australia
Voice +61-3-9791-9547 Data/BBS +61-3-9792-3507 3:632/348@fidonet
davidn@blaze.net.au http://www.blaze.net.au/~davidn
------------------------------
From: Michael Smith <msmith@atrad.adelaide.edu.au>
Date: Fri, 22 Nov 1996 11:53:27 +1030 (CST)
Subject: Re: Who needs Perl? We do!
Nate Williams stands accused of saying:
> >
> > Tcl is actually used for BMaking stuff, as you may have noticed.
> > Jordan is bolting the new install together using it. I'm working on
> > some configuration tools using it.
>
> Let's see those tools, and then I'll shutup. Again, there are lots of
Sure. Right now I'm taking gripes from my employer, my SO and the DOS
emulation people for the time I'm spending on my part; I don't
plan on wasting all that angst.
> essential. Should we bring in Python as well, and what about the new
> Limbo compiler from the folks at Lucent (nee Bell Labs). What about the
> ADA compiler from the GNU folks? Where do you draw the line between
> 'useful to some' and 'bloat'.
That is _exactly_ what this thread has been about; ref. my original
post. In my opinion, the usefulness of Perl in the base system
outweighs the 'bloat' consideration. I'm aware that bloat is an issue
of religious importance to some people, and I've been trying to
encourage one of these people (that isn't as overloaded as the rest of
us 8) to do something constructive about it without alienating the
"comfortable system" people by telling them to go pick a pile of
ports.
> It was decided a *LONG* time ago that unless a utility was part of the
> standard BSD distribution and/or was required for the running system it
> shouldn't be part of the tree.
That's all well and good, but it presents a chicken-and-egg situation
for anyone trying to work outside the decades-old BSD model. You may
not consider this a problem; I do. Opinions differ.
> FreeBSD is sold as a multi-user Unix system. 'ls' is required on that,
> and as well it's distributed as part of the 'standard BSD' tools.
I get this really sinking feeling around that whole concept. It's like
there's a little stack of yellowing 15x11 half-blue tractor-feed somewhere
with the Unix Commandments in faded courier on it, and that it exerts
this Powerful Force over all those that have read it, hardening their
hearts against anything not thought of at least ten years ago.
Maybe that as it should be; I just beg to differ.
> Nate
- --
]] Mike Smith, Software Engineer msmith@gsoft.com.au [[
]] Genesis Software genesis@gsoft.com.au [[
]] High-speed data acquisition and (GSM mobile) 0411-222-496 [[
]] realtime instrument control. (ph) +61-8-8267-3493 [[
]] Unix hardware collector. "Where are your PEZ?" The Tick [[
------------------------------
From: Nate Williams <nate@mt.sri.com>
Date: Thu, 21 Nov 1996 18:28:42 -0700 (MST)
Subject: Re: Who needs Perl? We do!
> > ADA compiler from the GNU folks? Where do you draw the line between
> > 'useful to some' and 'bloat'.
>
> That is _exactly_ what this thread has been about; ref. my original
> post. In my opinion, the usefulness of Perl in the base system
> outweighs the 'bloat' consideration.
Agreed (to a point).
> > It was decided a *LONG* time ago that unless a utility was part of the
> > standard BSD distribution and/or was required for the running system it
> > shouldn't be part of the tree.
>
> That's all well and good, but it presents a chicken-and-egg situation
> for anyone trying to work outside the decades-old BSD model. You may
> not consider this a problem; I do. Opinions differ.
Yes, but anyone capable of developing a 'cool tool' with TCL that we
can't live w/out is capable of installing a port, and *then* showing me
how wonderful it is to justify bringing in TCL as part of the base
system.
Put the cart *before* the horse.
Nate
------------------------------
End of hackers-digest V1 #1667
******************************
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199611270815_MC1-BC4-D910>