Bug 30772

On Sun, 23 Sep 2001 at 21:46:30 +0000, Peter Avalos wrote:
> >Fix:
> behaviour -> behavior


In light of this, i'm curious:  Is there any official position on which
of American or British spelling FreeBSD documentation should use?

-- 
Piet Delport <siberiyan@mweb.co.za>
Today's subliminal thought is:

Piet Delport <siberiyan@mweb.co.za> wrote:
>  On Sun, 23 Sep 2001 at 21:46:30 +0000, Peter Avalos wrote:
>  > >Fix:
>  > behaviour -> behavior
>  
>  In light of this, i'm curious:  Is there any official position on which
>  of American or British spelling FreeBSD documentation should use?

For documents in the doc/ tree, we use whatever is specified by the
locale name.  The English documents are delegated as en_US.ISO8859-1,
so we use US English.

For manual pages, both are acceptable, but it would be nice if just
one is used (i.e., as long as the word is spelled the same way
throughout the man page, regardless of whether it's British or US
spelling, it's okay).  Further, changing a spelling as a matter of
preference (US vs. British) or otherwise is strongly discouraged, so
this part of the change is wrong.  The other parts look okay, though,
so if the submitter could please back that part out, I'll apply this.

Thanks.

On Sun, Oct 14, 2001 at 04:40:01PM -0700, Dima Dorfman wrote:
>  For documents in the doc/ tree, we use whatever is specified by the
>  locale name.  The English documents are delegated as en_US.ISO8859-1,
>  so we use US English.

	I thought US English was also preferred for manpages. Thanks for
clearing this up, Dima.


--- blackhole.4	Tue Aug 14 04:58:07 2001
+++ blackhole.4.new	Sun Oct 14 18:44:29 2001
@@ -22,11 +22,8 @@
 MIB for manipulating behaviour in respect of refused TCP or UDP connection
 attempts
 .Sh SYNOPSIS
-.Cd sysctl net.inet.tcp.blackhole
-.Cd sysctl net.inet.udp.blackhole
-.Pp
-.Cd sysctl -w net.inet.tcp.blackhole=[0 | 1 | 2]
-.Cd sysctl -w net.inet.udp.blackhole=[0 | 1]
+.Cd sysctl net.inet.tcp.blackhole=[0 | 1 | 2]
+.Cd sysctl net.inet.udp.blackhole=[0 | 1]
 .Sh DESCRIPTION
 The
 .Nm
@@ -37,8 +34,8 @@
 Normal behaviour, when a TCP SYN segment is received on a port where
 there is no socket accepting connections, is for the system to return
 a RST segment, and drop the connection.  The connecting system will
-see this as a "Connection reset by peer".  By turning the TCP black
-hole MIB on to a numeric value of one, the incoming SYN segment
+see this as a "Connection reset by peer".  By setting the TCP blackhole
+MIB to a numeric value of one, the incoming SYN segment
 is merely dropped, and no RST is sent, making the system appear
 as a blackhole.  By setting the MIB value to two, any segment arriving
 on a closed port is dropped without returning a RST.  This provides
@@ -49,23 +46,23 @@
 arrives on a port where there is no socket listening.  It must be noted
 that this behaviour will prevent remote systems from running
 .Xr traceroute 8
-to your system.
+to a system.
 .Pp
 The blackhole behaviour is useful to slow down anyone who is port scanning
-your system, in order to try and detect vulnerable services on your system.
+a system, attempting to detect vulnerable services on a system.
 It could potentially also slow down someone who is attempting a denial
-of service against your system.
+of service attack.
 .Sh WARNING
 The TCP and UDP blackhole features should not be regarded as a replacement
 for
 .Xr ipfw 8
-as a tool for firewalling your system.  In order to create a highly
-secure system, you should use
+as a tool for firewalling a system.  In order to create a highly
+secure system,
 .Xr ipfw 8
-to protect your system, and not the blackhole feature.
+should be used for protection, not the blackhole feature.
 .Pp
-This mechanism is not a substitute for securing your system,
-but should be used together with other security mechanisms.
+This mechanism is not a substitute for securing a system.
+It should be used together with other security mechanisms.
 .Sh SEE ALSO
 .Xr ip 4 ,
 .Xr tcp 4 ,

Comment 4 dd 2001-10-15 14:30:55 UTC

State Changed
From-To: open->closed

Second patch applied, thanks!