From owner-svn-doc-head@FreeBSD.ORG Sun Sep 2 02:59:41 2012
Return-Path:
Delivered-To: svn-doc-head@freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34])
by hub.freebsd.org (Postfix) with ESMTP id B3EA2106564A;
Sun, 2 Sep 2012 02:59:41 +0000 (UTC)
(envelope-from eadler@FreeBSD.org)
Received: from svn.freebsd.org (svn.freebsd.org [IPv6:2001:4f8:fff6::2c])
by mx1.freebsd.org (Postfix) with ESMTP id 9EA568FC08;
Sun, 2 Sep 2012 02:59:41 +0000 (UTC)
Received: from svn.freebsd.org (localhost [127.0.0.1])
by svn.freebsd.org (8.14.4/8.14.4) with ESMTP id q822xfwA026755;
Sun, 2 Sep 2012 02:59:41 GMT (envelope-from eadler@svn.freebsd.org)
Received: (from eadler@localhost)
by svn.freebsd.org (8.14.4/8.14.4/Submit) id q822xfFU026753;
Sun, 2 Sep 2012 02:59:41 GMT (envelope-from eadler@svn.freebsd.org)
Message-Id: <201209020259.q822xfFU026753@svn.freebsd.org>
From: Eitan Adler
Date: Sun, 2 Sep 2012 02:59:41 +0000 (UTC)
To: doc-committers@freebsd.org, svn-doc-all@freebsd.org,
svn-doc-head@freebsd.org
X-SVN-Group: doc-head
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Cc:
Subject: svn commit: r39486 - head/en_US.ISO8859-1/articles/problem-reports
X-BeenThere: svn-doc-head@freebsd.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: SVN commit messages for the doc tree for head
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Sun, 02 Sep 2012 02:59:41 -0000
Author: eadler (src,ports committer)
Date: Sun Sep 2 02:59:41 2012
New Revision: 39486
URL: http://svn.freebsd.org/changeset/doc/39486
Log:
Move priority and severity into the "email template only section"
Approved by: wblock
Modified:
head/en_US.ISO8859-1/articles/problem-reports/article.sgml
Modified: head/en_US.ISO8859-1/articles/problem-reports/article.sgml
==============================================================================
--- head/en_US.ISO8859-1/articles/problem-reports/article.sgml Sat Sep 1 15:01:58 2012 (r39485)
+++ head/en_US.ISO8859-1/articles/problem-reports/article.sgml Sun Sep 2 02:59:41 2012 (r39486)
@@ -646,7 +646,7 @@
adding one or more email addresses to the
Cc: header.
- In the email template you will find the following two
+ In the email template only, you will find the following
single-line fields:
@@ -664,6 +664,47 @@
CVSup.
+
+ Severity: One of
+ non-critical,
+ serious or
+ critical. Do not overreact; refrain
+ from labeling your problem critical
+ unless it really is (e.g. data corruption issues, serious
+ regression from previous functionality in -CURRENT)
+ or serious unless
+ it is something that will affect many users (kernel
+ panics or freezes; problems with
+ particular device drivers or system utilities). &os;
+ developers will not necessarily work on your problem faster
+ if you inflate its importance since there are so many other
+ people who have done exactly that — in fact, some
+ developers pay little attention to this field
+ because of this.
+
+
+ Major security problems should not
+ be filed in GNATS, because all GNATS information is public
+ knowledge. Please send such problems in private email to
+ &a.security-officer;.
+
+
+
+
+ Priority: One of
+ low, medium or
+ high. high should
+ be reserved for problems that will affect practically
+ every user of &os; and medium for
+ something that will affect many users.
+
+
+ This field has become so widely abused that it is
+ almost completely meaningless.
+
+
+
+
The next section describes fields that are common to both
@@ -715,46 +756,6 @@
- Severity: One of
- non-critical,
- serious or
- critical. Do not overreact; refrain
- from labeling your problem critical
- unless it really is (e.g. data corruption issues, serious
- regression from previous functionality in -CURRENT)
- or serious unless
- it is something that will affect many users (kernel
- panics or freezes; problems with
- particular device drivers or system utilities). &os;
- developers will not necessarily work on your problem faster
- if you inflate its importance since there are so many other
- people who have done exactly that — in fact, some
- developers pay little attention to this field
- because of this.
-
-
- Major security problems should not
- be filed in GNATS, because all GNATS information is public
- knowledge. Please send such problems in private email to
- &a.security-officer;.
-
-
-
-
- Priority: One of
- low, medium or
- high. high should
- be reserved for problems that will affect practically
- every user of &os; and medium for
- something that will affect many users.
-
-
- This field has become so widely abused that it is
- almost completely meaningless.
-
-
-
- Category: Choose an appropriate
category.
From owner-svn-doc-head@FreeBSD.ORG Sun Sep 2 02:59:44 2012
Return-Path:
Delivered-To: svn-doc-head@freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52])
by hub.freebsd.org (Postfix) with ESMTP id 77EB61065670;
Sun, 2 Sep 2012 02:59:44 +0000 (UTC)
(envelope-from eadler@FreeBSD.org)
Received: from svn.freebsd.org (svn.freebsd.org [IPv6:2001:4f8:fff6::2c])
by mx1.freebsd.org (Postfix) with ESMTP id 6249C8FC0C;
Sun, 2 Sep 2012 02:59:44 +0000 (UTC)
Received: from svn.freebsd.org (localhost [127.0.0.1])
by svn.freebsd.org (8.14.4/8.14.4) with ESMTP id q822xinS026792;
Sun, 2 Sep 2012 02:59:44 GMT (envelope-from eadler@svn.freebsd.org)
Received: (from eadler@localhost)
by svn.freebsd.org (8.14.4/8.14.4/Submit) id q822xiNG026790;
Sun, 2 Sep 2012 02:59:44 GMT (envelope-from eadler@svn.freebsd.org)
Message-Id: <201209020259.q822xiNG026790@svn.freebsd.org>
From: Eitan Adler
Date: Sun, 2 Sep 2012 02:59:44 +0000 (UTC)
To: doc-committers@freebsd.org, svn-doc-all@freebsd.org,
svn-doc-head@freebsd.org
X-SVN-Group: doc-head
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Cc:
Subject: svn commit: r39487 - head/en_US.ISO8859-1/articles/problem-reports
X-BeenThere: svn-doc-head@freebsd.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: SVN commit messages for the doc tree for head
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Sun, 02 Sep 2012 02:59:44 -0000
Author: eadler (src,ports committer)
Date: Sun Sep 2 02:59:43 2012
New Revision: 39487
URL: http://svn.freebsd.org/changeset/doc/39487
Log:
Direct security reports to our guidelines instead of giving (incorrect)
information in our note.
While here fix a minor nit with "e.g.,"
Approved by: wblock
Modified:
head/en_US.ISO8859-1/articles/problem-reports/article.sgml
Modified: head/en_US.ISO8859-1/articles/problem-reports/article.sgml
==============================================================================
--- head/en_US.ISO8859-1/articles/problem-reports/article.sgml Sun Sep 2 02:59:41 2012 (r39486)
+++ head/en_US.ISO8859-1/articles/problem-reports/article.sgml Sun Sep 2 02:59:43 2012 (r39487)
@@ -670,7 +670,7 @@
serious or
critical. Do not overreact; refrain
from labeling your problem critical
- unless it really is (e.g. data corruption issues, serious
+ unless it really is (e.g., data corruption issues, serious
regression from previous functionality in -CURRENT)
or serious unless
it is something that will affect many users (kernel
@@ -683,10 +683,11 @@
because of this.
- Major security problems should not
+ Security problems should not
be filed in GNATS, because all GNATS information is public
- knowledge. Please send such problems in private email to
- &a.security-officer;.
+ knowledge. Please send such problems according to our
+ security
+ report guidelines.
From owner-svn-doc-head@FreeBSD.ORG Sun Sep 2 12:21:37 2012
Return-Path:
Delivered-To: svn-doc-head@freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52])
by hub.freebsd.org (Postfix) with ESMTP id B05BC106566C;
Sun, 2 Sep 2012 12:21:37 +0000 (UTC) (envelope-from cs@FreeBSD.org)
Received: from svn.freebsd.org (svn.freebsd.org [IPv6:2001:4f8:fff6::2c])
by mx1.freebsd.org (Postfix) with ESMTP id 8264A8FC08;
Sun, 2 Sep 2012 12:21:37 +0000 (UTC)
Received: from svn.freebsd.org (localhost [127.0.0.1])
by svn.freebsd.org (8.14.4/8.14.4) with ESMTP id q82CLba0000415;
Sun, 2 Sep 2012 12:21:37 GMT (envelope-from cs@svn.freebsd.org)
Received: (from cs@localhost)
by svn.freebsd.org (8.14.4/8.14.4/Submit) id q82CLb3u000412;
Sun, 2 Sep 2012 12:21:37 GMT (envelope-from cs@svn.freebsd.org)
Message-Id: <201209021221.q82CLb3u000412@svn.freebsd.org>
From: Carlo Strub
Date: Sun, 2 Sep 2012 12:21:37 +0000 (UTC)
To: doc-committers@freebsd.org, svn-doc-all@freebsd.org,
svn-doc-head@freebsd.org
X-SVN-Group: doc-head
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Cc:
Subject: svn commit: r39488 - head/en_US.ISO8859-1/books/porters-handbook
X-BeenThere: svn-doc-head@freebsd.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: SVN commit messages for the doc tree for head
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Sun, 02 Sep 2012 12:21:37 -0000
Author: cs (ports committer)
Date: Sun Sep 2 12:21:36 2012
New Revision: 39488
URL: http://svn.freebsd.org/changeset/doc/39488
Log:
Wrap long lines
Submitted by: wblock@ (via mail)
Modified:
head/en_US.ISO8859-1/books/porters-handbook/book.sgml
Modified: head/en_US.ISO8859-1/books/porters-handbook/book.sgml
==============================================================================
--- head/en_US.ISO8859-1/books/porters-handbook/book.sgml Sun Sep 2 02:59:43 2012 (r39487)
+++ head/en_US.ISO8859-1/books/porters-handbook/book.sgml Sun Sep 2 12:21:36 2012 (r39488)
@@ -3414,30 +3414,33 @@ ALWAYS_KEEP_DISTFILES= yes
COMMENTThis is a one-line description of the port.
- Please respect the following rules:
-
+ Please respect the following rules:
+ Try to keep the COMMENT value at no longer than 70
- characters, as this line will be used by the &man.pkg.info.1;
- utility to display a one-line summary of the port;
+ characters, as this line will be used by the
+ &man.pkg.info.1; utility to display a one-line summary
+ of the port;
- Do not include the package name
- (or version number of the software);
+ Do not include the package
+ name (or version number of the software);
- The comment should begin with a capital and end without a
- period;
+ The comment should begin with a capital and end
+ without a period;
- Do not start with an indefinite article (i.e. A or An);
+ Do not start with an indefinite article (i.e.
+ A or An);
- Names are capitalized (e.g. Apache, JavaScript, Perl);
+ Names are capitalized (e.g. Apache, JavaScript,
+ Perl);
- For lists of words use the Oxford comma (e.g. green,
- red, and blue);
+ For lists of words use the Oxford comma (e.g.
+ green, red, and blue);Spell check the text.
From owner-svn-doc-head@FreeBSD.ORG Sun Sep 2 13:13:19 2012
Return-Path:
Delivered-To: svn-doc-head@freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52])
by hub.freebsd.org (Postfix) with ESMTP id B5DB1106564A;
Sun, 2 Sep 2012 13:13:19 +0000 (UTC) (envelope-from cs@FreeBSD.org)
Received: from svn.freebsd.org (svn.freebsd.org [IPv6:2001:4f8:fff6::2c])
by mx1.freebsd.org (Postfix) with ESMTP id A03C28FC08;
Sun, 2 Sep 2012 13:13:19 +0000 (UTC)
Received: from svn.freebsd.org (localhost [127.0.0.1])
by svn.freebsd.org (8.14.4/8.14.4) with ESMTP id q82DDJRQ007161;
Sun, 2 Sep 2012 13:13:19 GMT (envelope-from cs@svn.freebsd.org)
Received: (from cs@localhost)
by svn.freebsd.org (8.14.4/8.14.4/Submit) id q82DDJ45007159;
Sun, 2 Sep 2012 13:13:19 GMT (envelope-from cs@svn.freebsd.org)
Message-Id: <201209021313.q82DDJ45007159@svn.freebsd.org>
From: Carlo Strub
Date: Sun, 2 Sep 2012 13:13:19 +0000 (UTC)
To: doc-committers@freebsd.org, svn-doc-all@freebsd.org,
svn-doc-head@freebsd.org
X-SVN-Group: doc-head
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Cc:
Subject: svn commit: r39489 - head/en_US.ISO8859-1/articles/contributors
X-BeenThere: svn-doc-head@freebsd.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: SVN commit messages for the doc tree for head
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Sun, 02 Sep 2012 13:13:19 -0000
Author: cs (ports committer)
Date: Sun Sep 2 13:13:19 2012
New Revision: 39489
URL: http://svn.freebsd.org/changeset/doc/39489
Log:
Add Paulo Fragoso
PR: ports/169891
Modified:
head/en_US.ISO8859-1/articles/contributors/contrib.additional.sgml
Modified: head/en_US.ISO8859-1/articles/contributors/contrib.additional.sgml
==============================================================================
--- head/en_US.ISO8859-1/articles/contributors/contrib.additional.sgml Sun Sep 2 12:21:36 2012 (r39488)
+++ head/en_US.ISO8859-1/articles/contributors/contrib.additional.sgml Sun Sep 2 13:13:19 2012 (r39489)
@@ -8063,6 +8063,11 @@
+ Paulo Fragoso
+ paulo@nlink.com.br
+
+
+ Paulo Menezes
paulo@isr.uc.pt
From owner-svn-doc-head@FreeBSD.ORG Sun Sep 2 14:15:54 2012
Return-Path:
Delivered-To: svn-doc-head@freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52])
by hub.freebsd.org (Postfix) with ESMTP id ABCB1106566B;
Sun, 2 Sep 2012 14:15:54 +0000 (UTC)
(envelope-from ryusuke@FreeBSD.org)
Received: from svn.freebsd.org (svn.freebsd.org [IPv6:2001:4f8:fff6::2c])
by mx1.freebsd.org (Postfix) with ESMTP id 9410F8FC18;
Sun, 2 Sep 2012 14:15:54 +0000 (UTC)
Received: from svn.freebsd.org (localhost [127.0.0.1])
by svn.freebsd.org (8.14.4/8.14.4) with ESMTP id q82EFsQn014928;
Sun, 2 Sep 2012 14:15:54 GMT (envelope-from ryusuke@svn.freebsd.org)
Received: (from ryusuke@localhost)
by svn.freebsd.org (8.14.4/8.14.4/Submit) id q82EFs8q014926;
Sun, 2 Sep 2012 14:15:54 GMT (envelope-from ryusuke@svn.freebsd.org)
Message-Id: <201209021415.q82EFs8q014926@svn.freebsd.org>
From: Ryusuke SUZUKI
Date: Sun, 2 Sep 2012 14:15:54 +0000 (UTC)
To: doc-committers@freebsd.org, svn-doc-all@freebsd.org,
svn-doc-head@freebsd.org
X-SVN-Group: doc-head
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Cc:
Subject: svn commit: r39490 - head/ja_JP.eucJP/htdocs/search
X-BeenThere: svn-doc-head@freebsd.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: SVN commit messages for the doc tree for head
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Sun, 02 Sep 2012 14:15:54 -0000
Author: ryusuke
Date: Sun Sep 2 14:15:53 2012
New Revision: 39490
URL: http://svn.freebsd.org/changeset/doc/39490
Log:
- Merge the following from the English version:
r37775 -> r39484 head/ja_JP.eucJP/htdocs/search/search.sgml
Modified:
head/ja_JP.eucJP/htdocs/search/search.sgml
Modified: head/ja_JP.eucJP/htdocs/search/search.sgml
==============================================================================
--- head/ja_JP.eucJP/htdocs/search/search.sgml Sun Sep 2 13:13:19 2012 (r39489)
+++ head/ja_JP.eucJP/htdocs/search/search.sgml Sun Sep 2 14:15:53 2012 (r39490)
@@ -4,7 +4,7 @@
]>
-
+
&header;
@@ -26,7 +26,6 @@
psim
From owner-svn-doc-head@FreeBSD.ORG Tue Sep 4 01:49:03 2012
Return-Path:
Delivered-To: svn-doc-head@freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34])
by hub.freebsd.org (Postfix) with ESMTP id B7930106566B;
Tue, 4 Sep 2012 01:49:03 +0000 (UTC)
(envelope-from eadler@FreeBSD.org)
Received: from svn.freebsd.org (svn.freebsd.org [IPv6:2001:4f8:fff6::2c])
by mx1.freebsd.org (Postfix) with ESMTP id A33528FC0A;
Tue, 4 Sep 2012 01:49:03 +0000 (UTC)
Received: from svn.freebsd.org (localhost [127.0.0.1])
by svn.freebsd.org (8.14.4/8.14.4) with ESMTP id q841n3Gx075497;
Tue, 4 Sep 2012 01:49:03 GMT (envelope-from eadler@svn.freebsd.org)
Received: (from eadler@localhost)
by svn.freebsd.org (8.14.4/8.14.4/Submit) id q841n3h2075495;
Tue, 4 Sep 2012 01:49:03 GMT (envelope-from eadler@svn.freebsd.org)
Message-Id: <201209040149.q841n3h2075495@svn.freebsd.org>
From: Eitan Adler
Date: Tue, 4 Sep 2012 01:49:03 +0000 (UTC)
To: doc-committers@freebsd.org, svn-doc-all@freebsd.org,
svn-doc-head@freebsd.org
X-SVN-Group: doc-head
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Cc:
Subject: svn commit: r39495 - head/en_US.ISO8859-1/htdocs/support
X-BeenThere: svn-doc-head@freebsd.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: SVN commit messages for the doc tree for head
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Tue, 04 Sep 2012 01:49:03 -0000
Author: eadler (src,ports committer)
Date: Tue Sep 4 01:49:03 2012
New Revision: 39495
URL: http://svn.freebsd.org/changeset/doc/39495
Log:
Encourage the use of the PR system instead of a (bogus) mailing list for
sending bug reports.
Approved by: gjb
Modified:
head/en_US.ISO8859-1/htdocs/support/bugreports.sgml
Modified: head/en_US.ISO8859-1/htdocs/support/bugreports.sgml
==============================================================================
--- head/en_US.ISO8859-1/htdocs/support/bugreports.sgml Mon Sep 3 19:47:51 2012 (r39494)
+++ head/en_US.ISO8859-1/htdocs/support/bugreports.sgml Tue Sep 4 01:49:03 2012 (r39495)
@@ -39,12 +39,10 @@
Problem reports may be submitted to the development team using the
send-pr(1)
- command on a &os; system. Another way to submit a problem report is
- to use the web based form,
- or by sending an email message to freebsd-bugs@FreeBSD.org.
- Please note that send-pr is preferred
- since messages sent to the mailing list are not tracked as
+ command on a &os; system or by
+ using the web based form.
+ Please note that
+ messages sent to a mailing list are not tracked as
official problem reports, and may get lost in the noise!
Before submitting a problem report, you might find it useful to
From owner-svn-doc-head@FreeBSD.ORG Tue Sep 4 01:59:07 2012
Return-Path:
Delivered-To: svn-doc-head@freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52])
by hub.freebsd.org (Postfix) with ESMTP id A8E841065670;
Tue, 4 Sep 2012 01:59:07 +0000 (UTC)
(envelope-from eadler@FreeBSD.org)
Received: from svn.freebsd.org (svn.freebsd.org [IPv6:2001:4f8:fff6::2c])
by mx1.freebsd.org (Postfix) with ESMTP id 94BB18FC08;
Tue, 4 Sep 2012 01:59:07 +0000 (UTC)
Received: from svn.freebsd.org (localhost [127.0.0.1])
by svn.freebsd.org (8.14.4/8.14.4) with ESMTP id q841x72M076580;
Tue, 4 Sep 2012 01:59:07 GMT (envelope-from eadler@svn.freebsd.org)
Received: (from eadler@localhost)
by svn.freebsd.org (8.14.4/8.14.4/Submit) id q841x7tp076578;
Tue, 4 Sep 2012 01:59:07 GMT (envelope-from eadler@svn.freebsd.org)
Message-Id: <201209040159.q841x7tp076578@svn.freebsd.org>
From: Eitan Adler
Date: Tue, 4 Sep 2012 01:59:07 +0000 (UTC)
To: doc-committers@freebsd.org, svn-doc-all@freebsd.org,
svn-doc-head@freebsd.org
X-SVN-Group: doc-head
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Cc:
Subject: svn commit: r39496 - head/en_US.ISO8859-1/books/faq
X-BeenThere: svn-doc-head@freebsd.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: SVN commit messages for the doc tree for head
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Tue, 04 Sep 2012 01:59:07 -0000
Author: eadler (src,ports committer)
Date: Tue Sep 4 01:59:07 2012
New Revision: 39496
URL: http://svn.freebsd.org/changeset/doc/39496
Log:
This is no longer good advice to provide in order to fix issues:
many modern systems can't boot with acpi disabled; it may be a good
suggestion for some rare case not for an FAQ.
Approved by: gjb
Modified:
head/en_US.ISO8859-1/books/faq/book.sgml
Modified: head/en_US.ISO8859-1/books/faq/book.sgml
==============================================================================
--- head/en_US.ISO8859-1/books/faq/book.sgml Tue Sep 4 01:49:03 2012 (r39495)
+++ head/en_US.ISO8859-1/books/faq/book.sgml Tue Sep 4 01:59:07 2012 (r39496)
@@ -2080,28 +2080,6 @@
shows up before loader is started.
-
-
-
- Installation crashes while booting, what can I do?
-
-
-
- Try disabling ACPI support. When the bootloader loads,
- press the Space key. The system will display
- the following:
-
- OK
-
- Type:
-
- unset acpi_load
-
- And then type:
-
- boot
-
-
From owner-svn-doc-head@FreeBSD.ORG Tue Sep 4 09:50:13 2012
Return-Path:
Delivered-To: svn-doc-head@freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34])
by hub.freebsd.org (Postfix) with ESMTP id BDB891065670;
Tue, 4 Sep 2012 09:50:13 +0000 (UTC)
(envelope-from ryusuke@FreeBSD.org)
Received: from svn.freebsd.org (svn.freebsd.org [IPv6:2001:4f8:fff6::2c])
by mx1.freebsd.org (Postfix) with ESMTP id 8FC068FC08;
Tue, 4 Sep 2012 09:50:13 +0000 (UTC)
Received: from svn.freebsd.org (localhost [127.0.0.1])
by svn.freebsd.org (8.14.4/8.14.4) with ESMTP id q849oDL2031654;
Tue, 4 Sep 2012 09:50:13 GMT (envelope-from ryusuke@svn.freebsd.org)
Received: (from ryusuke@localhost)
by svn.freebsd.org (8.14.4/8.14.4/Submit) id q849oDVA031652;
Tue, 4 Sep 2012 09:50:13 GMT (envelope-from ryusuke@svn.freebsd.org)
Message-Id: <201209040950.q849oDVA031652@svn.freebsd.org>
From: Ryusuke SUZUKI
Date: Tue, 4 Sep 2012 09:50:13 +0000 (UTC)
To: doc-committers@freebsd.org, svn-doc-all@freebsd.org,
svn-doc-head@freebsd.org
X-SVN-Group: doc-head
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Cc:
Subject: svn commit: r39497 - head/ja_JP.eucJP/htdocs/support
X-BeenThere: svn-doc-head@freebsd.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: SVN commit messages for the doc tree for head
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Tue, 04 Sep 2012 09:50:13 -0000
Author: ryusuke
Date: Tue Sep 4 09:50:13 2012
New Revision: 39497
URL: http://svn.freebsd.org/changeset/doc/39497
Log:
- Merge the following from the English version and refine translation.
r38675 -> r39495 head/ja_JP.eucJP/htdocs/support/bugreports.sgml
Modified:
head/ja_JP.eucJP/htdocs/support/bugreports.sgml
Modified: head/ja_JP.eucJP/htdocs/support/bugreports.sgml
==============================================================================
--- head/ja_JP.eucJP/htdocs/support/bugreports.sgml Tue Sep 4 01:59:07 2012 (r39496)
+++ head/ja_JP.eucJP/htdocs/support/bugreports.sgml Tue Sep 4 09:50:13 2012 (r39497)
@@ -6,7 +6,7 @@
]>
-
+
&header;
@@ -27,7 +27,7 @@
¥³¥ì¥¯¥·¥ç¥ó¤Ë²Ã¤¨¤ë¤¿¤á¤Ë½àÈ÷¤µ¤ì¤¿ port ¤Ë´Ø¤·¤Æ¤ÎÊó¹ð¤Ç¤¹¡£
¾ã³²Êó¹ð¤Ï 'open'
- ¾õÂÖ¤«¤é»Ï¤Þ¤ê¡¢Êó¹ð¤µ¤ì¤¿ÌäÂ꤬²ò·è¤¹¤ë¤ÈÊĤ¸¤é¤ì¤Þ¤¹¡£
+ ¾õÂÖ¤«¤é»Ï¤Þ¤ê¡¢Êó¹ð¤µ¤ì¤¿ÌäÂ꤬²ò·è¤¹¤ë¤È 'closed' ¤Ë¤Ê¤ê¤Þ¤¹¡£
¤Ê¤ª¡¢¸«¼º¤¦¤³¤È¤¬¤Ê¤¤¤è¤¦¤Ë¡¢³Æ¾ã³²Êó¹ð¤Ë¤Ï¸ÇͤÎÄÉÀ× ID
¤¬³ä¤êÅö¤Æ¤é¤ì¤Þ¤¹¡£FreeBSD
¤Ë²Ã¤¨¤é¤ì¤¿Êѹ¹¤ÎÍúÎò¤Ë¤Ï¡¢¤½¤ÎÊѹ¹¤òÂ¥¤·¤¿¾ã³²Êó¹ð¤ÎÄÉÀ× ID
@@ -42,16 +42,13 @@
@@ -308,9 +311,8 @@
&a.hackers;. Da mesma forma, pessoas com interesse neste tipo
de assunto (e uma tolerância para um
alto volume de mensagens!), devem se
- inscrever na &a.hackers; através do envio de um e-mail
- para &a.majordomo;. Consulte o &a.ptbr.p.handbook;
+ inscrever na &a.hackers;. Consulte o &a.ptbr.p.handbook;
para maiores informações sobre esta e outras
listas de discussão.
@@ -318,7 +320,7 @@
alteração específica; por favor,
faça o relatório utilizando o programa
&man.send-pr.1; ou a sua interface WWW
+ url="&url.base;/send-pr.html">interface WWW
equivalente. A não ser que ele exceda 65KB,
inclua qualquer patch diretamente no
relatório. Se o patch é
@@ -329,16 +331,17 @@
faça utilizando copiar-e-colar porque ao copiar-e-colar
os tabs serão convertidos para
espaços, e tornará o patch
- inutilizável. Se o patch
- ultrapassar 20KB considere a possibilidade de comprimi-lo e
- utilizar o &man.uuencode.1; antes de enviá-lo.
+ inutilizável. Quando os patches
+ forem muito maiores que 20KB, considere a possibilidade de
+ comprimi-los (por ex. usando &man.gzip.1; or &man.bzip2.1;) e
+ utilize o &man.uuencode.1; para incluir a versão
+ compactada no seu relatório de problema.
Depois de enviar o relatório, voce deve receber uma
confirmação junto com um número de
registro. Guarde este número de registro, de forma que
você possa nos manter atualizados sobre o seu problema
- enviando um e-mail para
- bug-followup@FreeBSD.org. Coloque o
+ enviando um e-mail para &a.bugfollowup;. Coloque o
número no assunto da mensagem, por ex. "Re:
kern/3377". Informações adicionais
sobre qualquer relatório de problema
@@ -354,7 +357,7 @@
e-mail para &a.bugs;.Consulte também este
+ URL="&url.articles.problem-reports;/article.html">este
artigo sobre como escrever um bom relatório
de problema.
@@ -363,13 +366,14 @@
Alterações na
Documentação
- Envio de
- documentação
+
+ Envio de documentação
+ Alterações na documentação
são administradas pela &a.doc;. Por favor, verifique o
&a.ptbr.p.fdpp;
+ url="&url.books.fdp-primer;/index.html">&a.ptbr.p.fdpp;
para obter instruções detalhadas. Envie suas
colaborações e alterações
(inclusive as pequenas são bem vindas!) usando o
@@ -395,7 +399,7 @@
em uma grande variedade de formas para a comodidade dos
desenvolvedores que trabalham ativamente no sistema. Consulte
o &a.ptbr.p.handbook;
+ &url.books.handbook;/current-stable.html">&a.ptbr.p.handbook;
para maiores informações sobre como obter e
utilizar o FreeBSD-CURRENT.
@@ -431,19 +435,25 @@
Por exemplo:
-
- &prompt.user; diff -c oldfile newfile
- ou
- &prompt.user; diff -c -r olddir newdir
- geraria o tal conjunto de diffs de contexto
- para um dado arquivo de código ou para uma hierarquia
- de diretórios.
-
- Da mesma forma,
- &prompt.user; diff -u oldfile newfile
- ou
- &prompt.user; diff -u -r olddir newdir
- faria o mesmo, exceto que utilizando o formato de
+ &prompt.user; diff -c oldfile newfile
+
+ ou
+
+ &prompt.user; diff -c -r olddir newdir
+
+ geraria o tal conjunto de diffs de
+ contexto para um dado arquivo de código ou para uma
+ hierarquia de diretórios.
+
+ Da mesma forma,
+
+ &prompt.user; diff -u oldfile newfile
+
+ ou
+
+ &prompt.user; diff -u -r olddir newdir
+
+ faria o mesmo, exceto que utilizando o formato de
diff unificado.Consulte o manual do &man.diff.1; para maiores
@@ -527,7 +537,9 @@
são:
- Licensa BSD
+
+ Licensa BSD
+ Os direitos autorais BSD. Este tipo de licensa
@@ -540,12 +552,14 @@
investimentos no próprio FreeBSD.
- GPLGNU General Public
- License
-
- Licença Pública Geral GNU
+
+ GPLGNU General Public License
+
+
+ Licença Pública Geral GNU
(GNU General Public
- License)
+ License)
+ A licensa pública geral GNU, ou
@@ -559,10 +573,11 @@
contribuições adicionais sob esta licensa.
O código sob a GPL também vai para uma parte
diferente da árvore, mais especificamente para
- /sys/gnu ou
- /usr/src/gnu, de forma que é
- muito fácil identificá-lo para qualquer um
- que a GPL representa um problema.
+ /sys/gnu ou
+ /usr/src/gnu, de
+ forma que é muito fácil
+ identificá-lo para qualquer um que a GPL
+ representa um problema.
@@ -640,12 +655,14 @@ THIS SOFTWARE, EVEN IF ADVISED OF THE PO
dedutíveis dos impostos federais.
As doações podem ser enviadas
- através de cheques para: The FreeBSD
- Foundation 7321 Brockway Dr.
- Boulder, CO
- 80303USA
-
-
+ através de cheques para:
+
+ The FreeBSD Foundation
+ 7321 Brockway Dr.
+ Boulder,
+ CO, 80303
+ USA
+
A Fundação FreeBSD é agora capaz de
receber doações através da web com o
@@ -666,17 +683,19 @@ THIS SOFTWARE, EVEN IF ADVISED OF THE PO
Doando Hardware
- doacões
+
+ doacões
+ O projeto de FreeBSD aceita alegremente
doações de
hardware para as quais pode
encontrar bom uso. Se voce estiver interessado em doar
componentes de hardware; por
- favor, contate o Escritório
- de Relacionamento com Doadores.
-
+ favor, contate o
+ Escritório de
+ Relacionamento com Doadores.
+
Doando Acesso Internet
@@ -685,18 +704,9 @@ THIS SOFTWARE, EVEN IF ADVISED OF THE PO
espelho para os serviços de FTP, WWW ou
cvsup. Se você desejar se tornar
um sítio espelho; por favor, consulte o artigo Espelhando o FreeBSD
- para maiores informações.
+ url="&url.articles.hubs;/index.html">Espelhando o
+ FreeBSD para maiores informações.
-
-
Modified: head/pt_BR.ISO8859-1/share/sgml/mailing-lists.ent
==============================================================================
--- head/pt_BR.ISO8859-1/share/sgml/mailing-lists.ent Wed Sep 5 05:24:57 2012 (r39501)
+++ head/pt_BR.ISO8859-1/share/sgml/mailing-lists.ent Wed Sep 5 05:32:52 2012 (r39502)
@@ -4,10 +4,14 @@
The FreeBSD Documentation Project
The FreeBSD Brazilian Portuguese Documentation Project
- Original revision: 1.1
+ Original revision: r38826
$FreeBSD$
-->
+
+FreeBSD list server">
+&a.mailman.listinfo;">
+
advocacy
[English Content/Conteúdo em Inglês]
@@ -256,10 +260,9 @@
[English Content/Conteúdo em Inglês]
freebsd-qa@FreeBSD.org">
-freebsd-questions@FreeBSD.org">
+
+lista de discussão do FreeBSD de perguntas genéricas [English Content/Conteúdo em Inglês]">
+freebsd-questions">
freebsd-www@FreeBSD.org">
majordomo@FreeBSD.org">
+bug-followup@FreeBSD.org">
+
From owner-svn-doc-head@FreeBSD.ORG Wed Sep 5 05:38:12 2012
Return-Path:
Delivered-To: svn-doc-head@freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34])
by hub.freebsd.org (Postfix) with ESMTP id 25453106564A;
Wed, 5 Sep 2012 05:38:12 +0000 (UTC)
(envelope-from gabor@FreeBSD.org)
Received: from svn.freebsd.org (svn.freebsd.org [IPv6:2001:4f8:fff6::2c])
by mx1.freebsd.org (Postfix) with ESMTP id 0EE478FC0C;
Wed, 5 Sep 2012 05:38:12 +0000 (UTC)
Received: from svn.freebsd.org (localhost [127.0.0.1])
by svn.freebsd.org (8.14.4/8.14.4) with ESMTP id q855cBNF081761;
Wed, 5 Sep 2012 05:38:11 GMT (envelope-from gabor@svn.freebsd.org)
Received: (from gabor@localhost)
by svn.freebsd.org (8.14.4/8.14.4/Submit) id q855cB61081757;
Wed, 5 Sep 2012 05:38:11 GMT (envelope-from gabor@svn.freebsd.org)
Message-Id: <201209050538.q855cB61081757@svn.freebsd.org>
From: Gabor Kovesdan
Date: Wed, 5 Sep 2012 05:38:11 +0000 (UTC)
To: doc-committers@freebsd.org, svn-doc-all@freebsd.org,
svn-doc-head@freebsd.org
X-SVN-Group: doc-head
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Cc:
Subject: svn commit: r39503 - in head/pt_BR.ISO8859-1/articles: .
problem-reports
X-BeenThere: svn-doc-head@freebsd.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: SVN commit messages for the doc tree for head
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Wed, 05 Sep 2012 05:38:12 -0000
Author: gabor
Date: Wed Sep 5 05:38:11 2012
New Revision: 39503
URL: http://svn.freebsd.org/changeset/doc/39503
Log:
- Add new Brazilian Portuguese translation of the problem-reports article
PR: docs/170672
Submitted by: Edson Brandi
Obtained from: The FreeBSD Brazilian Portuguese Documentation Project
(http://doc.fug.com.br)
Added:
head/pt_BR.ISO8859-1/articles/problem-reports/
head/pt_BR.ISO8859-1/articles/problem-reports/Makefile (contents, props changed)
head/pt_BR.ISO8859-1/articles/problem-reports/article.sgml (contents, props changed)
Modified:
head/pt_BR.ISO8859-1/articles/Makefile
Modified: head/pt_BR.ISO8859-1/articles/Makefile
==============================================================================
--- head/pt_BR.ISO8859-1/articles/Makefile Wed Sep 5 05:32:52 2012 (r39502)
+++ head/pt_BR.ISO8859-1/articles/Makefile Wed Sep 5 05:38:11 2012 (r39503)
@@ -11,6 +11,7 @@
SUBDIR =
SUBDIR+= contributing
SUBDIR+= linux-users
+SUBDIR+= problem-reports
DOC_PREFIX?= ${.CURDIR}/../..
.include "${DOC_PREFIX}/share/mk/doc.project.mk"
Added: head/pt_BR.ISO8859-1/articles/problem-reports/Makefile
==============================================================================
--- /dev/null 00:00:00 1970 (empty, because file is newly added)
+++ head/pt_BR.ISO8859-1/articles/problem-reports/Makefile Wed Sep 5 05:38:11 2012 (r39503)
@@ -0,0 +1,24 @@
+#
+# The FreeBSD Documentation Project
+# The FreeBSD Brazilian Portuguese Documentation Project
+#
+# $FreeBSD$
+#
+# Original revision: r38826
+#
+# Article: Writing FreeBSD Problem Reports
+
+DOC?= article
+
+FORMATS?= html html-split
+WITH_ARTICLE_TOC?= YES
+
+INSTALL_COMPRESSED?=gz
+INSTALL_ONLY_COMPRESSED?=
+
+SRCS= article.sgml
+
+URL_RELPREFIX?= ../../../..
+DOC_PREFIX?= ${.CURDIR}/../../..
+
+.include "${DOC_PREFIX}/share/mk/doc.project.mk"
Added: head/pt_BR.ISO8859-1/articles/problem-reports/article.sgml
==============================================================================
--- /dev/null 00:00:00 1970 (empty, because file is newly added)
+++ head/pt_BR.ISO8859-1/articles/problem-reports/article.sgml Wed Sep 5 05:38:11 2012 (r39503)
@@ -0,0 +1,1644 @@
+
+
+
+%articles.ent;
+]>
+
+
+
+ Escrevendo Relatórios de Problema no &os;
+
+ $FreeBSD$
+
+
+ &tm-attrib.freebsd;
+ &tm-attrib.cvsup;
+ &tm-attrib.ibm;
+ &tm-attrib.intel;
+ &tm-attrib.sparc;
+ &tm-attrib.sun;
+ &tm-attrib.general;
+
+
+
+ Este artigo descreve qual a melhor forma de formular e
+ de submeter um relatório de problema para Projeto
+ &os;.
+
+
+
+
+ Dag-Erling
+ Smørgrav
+ Contribuido por
+
+
+
+ Mark
+ Linimon
+
+
+
+
+ relatório de problema
+
+
+
+ Introdução
+
+ Uma das experiências mais frustrantes que
+ alguém pode ter como um usuário de um software
+ é submeter um relatório sobre um problema
+ que está enfrentando apenas para vê-lo ser
+ sumariamente fechado com uma informação curta
+ e pouco útil do tipo isto não é
+ um bug ou ainda este relatório de
+ problema não procede. Da mesma forma, uma das
+ experiências mais frustrantes para um desenvolvedor de
+ software é ser inundado com relatórios de
+ problemas que na verdade não são realmente
+ relatórios de problemas, mas sim
+ solicitações de suporte, ou então que
+ contenham pouca ou nenhuma informação sobre como
+ o problema ocorre e sobre como proceder para
+ reproduzi-lo.
+
+ Este documento tem por objetivo descrever como escrever
+ bons relatórios de problema. Mas o que vem a ser um
+ bom relatório de problema? Bem, indo direto ao ponto,
+ um bom relatório de problema é aquele que se
+ pode analisar e tratar rapidamente, para a
+ satisfação mútua do usuário e do
+ desenvolvedor.
+
+ Embora o foco primário deste artigo seja a
+ elaboração de relatórios de problemas no
+ &os;, a maior parte das recomendações deve
+ aplicar-se muito bem a outros projetos de software.
+
+ Observe que este artigo esta organizado de forma
+ temática, e não de forma cronológica,
+ desta forma você deve ler o documento inteiro antes
+ de enviar um relatório de problema, ao invés
+ de tratá-lo como um tutorial passo-a-passo.
+
+
+
+ Quando enviar um relatório de problema
+
+ Existem muitos tipos de problemas, e nem todos eles devem
+ gerar um relatório de problema. É claro,
+ ninguém é perfeito e em algumas ocasiões
+ você terá certeza de que encontrou um bug em um
+ determinado software quando na verdade você compreendeu
+ errado a sintaxe de um comando ou mesmo cometeu um erro de
+ digitação em um arquivo de
+ configuração (o que por sua vez pode indicar
+ uma documentação pouco detalhada ou
+ então um tratamento inadequado do erro por parte
+ da aplicação). Existem ainda muitas outras
+ situações nas quais enviar um relatório de
+ problema claramente não é
+ a melhor ação a ser tomada, e só vai
+ servir para frustrar a você e aos desenvolvedores. Em
+ contrapartida, existem situações nas quais
+ é recomendado que você nos envie um
+ relatório de problema sobre outras coisas que
+ não um bug, como por exemplo para nos enviar uma
+ sugestão de melhoria ou um pedido de uma nova
+ funcionalidade.
+
+ Então como você irá diferenciar o que
+ é e o que não é um bug? Existe uma regra
+ de ouro que diz que o seu problema não
+ é um bug se ele pode ser expresso como uma
+ pergunta (normalmente na forma Como eu faço
+ X ou Onde eu posso encontrar Y). Na
+ maior parte das vezes não será sempre
+ tão claro desta forma, mas a regra acima cobre a grande
+ maioria dos casos. Se você estiver procurando por uma
+ resposta, considere enviar a sua pergunta para
+ &a.questions;.
+
+ Veja alguns casos nos quais pode ser apropriado enviar um
+ relatório de problema sobre algo que não é
+ um bug:
+
+
+
+ Pedidos de melhorias nas funcionalidades. Geralmente
+ é uma boa idéia debater estas propostas nas
+ listas de discussão antes de enviá-las em um
+ relatório de problemas.
+
+
+
+ Notificações sobre
+ atualizações de softwares mantidos
+ externamente (principalmente do ports, mas também
+ de componentes do sistema base como, por exemplo, o BIND e
+ vários outros utilitários GNU).
+
+ Para os ports sem manutenção
+ (aqueles nos quais a variável
+ MAINTAINER contém
+ ports@FreeBSD.org), essas
+ notificações de atualização
+ podem ser capturadas por um committer
+ interessado, ou você pode ser solicitado a fornecer
+ um patch para atualizar o port;
+ disponibilizar este patch antecipadamente
+ irá melhorar de forma significativa as suas chances
+ de ter o port atualizado rapidamente.
+
+ Se o port possui um mantenedor, o envio de um
+ relatório de problema comunicando sobre o
+ lançamento de uma nova versão geralmente
+ não é muito útil uma vez que eles geram
+ trabalho adicional para os committers,
+ e o mantenedor provavelmente já tem conhecimento de
+ que existe uma nova versão, ele provavelmente
+ já trabalhou com os desenvolvedores para
+ atualizá-lo e está provavelmente executando
+ testes para verificar se não existem problemas,
+ etc.
+
+ Em ambos os casos, você irá obter melhores
+ resultados se seguir o processo descrito no Porter's Handbook.
+ (Talvez você também queira ler o artigo
+ Contribuindo para a Coleção de Ports
+ do &os;.)
+
+
+
+ Um bug que não pode ser reproduzido, raramente
+ será corrigido. Se o bug ocorreu uma única
+ vez e você não consegue reproduzi-lo, e
+ se aparentemente ele não ocorre com mais ninguém,
+ as chances são de que nenhum dos desenvolvedores
+ será capaz de reproduzir ou de saber o que está
+ errado. Isso não significa que não seja
+ possível, mas significa que a probabilidade do seu
+ relatório de problema resultar na correção
+ do bug é muito pequena. Para piorar a
+ situação, muitas vezes este tipo de erro
+ é, na realidade, causado por falhas nos discos
+ rígidos ou por superaquecimento do processador —
+ sempre que possível você deve tentar excluir estas
+ causas antes de enviar um relatório de problema.
+
+ Em seguida, para decidir a quem você deve apresentar
+ o seu relatório de problema, você precisa
+ entender que o &os; é composto de vários
+ elementos de software diferentes:
+
+
+
+ Código na base do sistema que é escrito
+ e mantido por colaboradores do &os;, tais como o Kernel, a
+ biblioteca C, os drivers de dispositivos (categorizados
+ como kern); os utilitários
+ binários (bin); as páginas
+ de manual e a documentação
+ (docs); e as páginas web
+ (www). Todos os bugs nestas
+ áreas devem ser reportados para os desenvolvedores
+ do &os;
+
+
+
+ Código na base do sistema que é escrito
+ e mantido por outros, e que foram adaptados e importados
+ no &os;. Exemplos incluen bind,
+ &man.gcc.1;, e &man.sendmail.8;. A maioria dos bugs nestas
+ áreas devem ser reportados para os desenvolvedores do
+ &os;; mas em alguns casos pode ser necessário
+ reportá-los aos autores originais, caso o problema
+ não seja especifico do &os;. Normalmente estes bugs
+ irão ficar sob as categorias bin
+ ou gnu.
+
+
+
+ Os aplicativos individuais que não estão
+ na base do sistema, mas que fazem parte da
+ coleção de Ports do &os; (Categoria
+ ports). A maioria destes aplicativos
+ não são escritos por desenvolvedores do
+ &os;; o que o &os; oferece é apenas um sistema para
+ facilitar a instalação do aplicativo.
+ Portanto, você deve relatar um problema para os
+ desenvolvedores do &os; apenas quando você acreditar
+ que o problema é específico do &os;, caso
+ contrário, você deve reportá-lo aos
+ autores do software.
+
+
+
+
+ A seguir você deve verificar se o problema é
+ ou não atual. Existem poucas coisas que aborrecem um
+ desenvolvedor mais do que receber um relatório de
+ problema a respeito de um bug que ele já corrigiu.
+
+ Se o problema está na base do sistema, você
+ deverá primeiro ler a seção do FAQ sobre
+
+ Versões do &os;, se você não estiver
+ familiarizado com o tema. Não é possível
+ para o &os; corrigir problemas em versões muito antigas
+ do sistema base, desta forma enviar um relatório de
+ problema sobre um bug em uma versão muito antiga vai
+ provavelmente resultar apenas em um desenvolvedor aconselhando
+ que você atualize o seu sistema para uma versão
+ suportada para ver se o problema ainda ocorre. A equipe
+ de Security Officer mantém a
+ lista de versões
+ suportadas.
+
+ Se o problema está em um port, observe que
+ você deverá primeiro atualizar seu sistema para a
+ versão mais atual da coleção de ports e ver
+ se o problema ainda se aplica. Devido ao ritmo acelerado de
+ mudanças nestas aplicações, é
+ inviável para o &os; suportar qualquer coisa que
+ não seja obrigatoriamente a versão mais
+ recente, e problemas com uma versão antiga do
+ aplicativo simplesmente não podem ser corrigidos.
+
+
+
+ Preparação
+
+ Uma boa regra a ser seguida sempre é realizar uma
+ busca a respeito do assunto antes de enviar um relatório
+ de problema. Pode ser que o seu problema já tenha sido
+ reportado anteriormente; pode ser que esteja sendo debatido nas
+ listas de discussão ou que tenha sido recentemente; pode
+ até ser que o problema já tenha sido corrigido em
+ uma versão mais recente do que a que você
+ está utilizando. Você deve portanto verificar
+ em todos os lugares óbvios antes de enviar o
+ relatório de problema. Para o &os;, isto
+ significa:
+
+
+
+ A lista de Perguntas e Respostas mais
+ Frequentes sobre o &os; (FAQ). A FAQ tem por
+ objetivo fornecer respostas para uma grande variedade de
+ perguntas, tais como as que dizem respeito a compatibilidade de
+ hardware, aplicações
+ do usuário, Configuração
+ do kernel, etc.
+
+
+
+ As
+ listas de discussão — se você
+ não está inscrito, utilize a
+ busca do histórico no web site do
+ &os;. Se o seu problema não tiver sido discutido nas
+ listas, você pode tentar enviar uma mensagem sobre ele
+ e aguardar alguns dias para ver se alguém consegue
+ perceber algo que você tenha deixado passar
+ desapercebido.
+
+
+
+ Opcionalmente, na internet inteira — utilize seu
+ mecanismo de busca preferido para localizar
+ referências sobre o seu problema. Você pode
+ encontrar referências a ele em mensagens de listas de
+ discussão ou de grupos de noticias dos quais
+ você nunca ouviu falar ou nos quais sequer pensou
+ em procurar.
+
+
+
+ Na sequência, verifique o
+ banco de dados com os relatórios de problema do
+ &os; (GNATS). A menos que o seu problema seja
+ recente ou muito obscuro, existe uma boa chance dele
+ já ter sido reportado.
+
+
+
+ E o mais importante, você deve verificar se a
+ documentação existente no código base
+ não endereça o seu problema.
+
+ Para o código base do &os; você deve
+ estudar cuidadosamente o conteúdo do arquivo
+ /usr/src/UPDATING disponível no
+ seu sistema de arquivos ou a sua versão mais
+ recente no
+ Repositório Subversion. (Esta
+ informação é vital se você
+ estiver atualizando de uma versão para outra
+ — especialmente se estiver atualizando para o
+ &os.current;).
+
+ No entanto, se o problema é com algo que foi
+ instalado como uma parte da coleção de ports
+ do &os; você deve consultar o
+ /usr/ports/UPDATING (para os ports
+ individuais) ou o /usr/ports/CHANGES
+ (para mudanças que afetam a Coleção de
+ Ports inteira). Estes arquivos também estão
+ disponíveis no SVNWeb, nos urls
+ e
+ respectivamente.
+
+
+
+
+
+ Escrevendo o Relatório de Problema
+
+ Agora que você decidiu que o seu assunto merece um
+ relatório de problema (PR), e que ele é um
+ problema do &os;, é hora de escrever o relatório
+ em si. Mas antes de entrarmos na mecânica do programa
+ utilizado para gerar e enviar os PRs, aqui estão
+ algumas dicas e truques para ajudá-lo a garantir que o
+ seu PR será o mais efetivo possível.
+
+
+ Dicas e truques para escrever um bom relatório de
+ problema.
+
+
+
+ Não deixe a linha de
+ Synopsis (sinopse) em branco.
+ Os PRs são enviados para listas de discussão
+ no mundo todo (nas quais a Synopsis
+ é utilizada como linha de
+ Subject:), além de serem
+ armazenados em um banco de dados. Qualquer pessoa
+ que vier a navegar no banco de dados pelas
+ sinopses, e encontrar um PR com a linha de assunto
+ em branco, tende a pulá-lo. Lembre-se que os PRs
+ permanecem na base de dados até que sejam fechados
+ por alguém; os anônimos normalmente
+ irão desaparecer em meio ao ruído.
+
+
+
+ Evite utilizar uma Synopsis
+ (sinopse) fraca. Você não
+ pode assumir que alguém que esteja lendo o seu PR
+ conheça todo o contexto que motivou o seu envio,
+ desta forma quanto mais informação
+ você fornecer, melhor. Por exemplo, a que
+ parte do sistema o problema se aplica? O problema
+ ocorre durante a instalação ou durante a
+ execução do sistema? Para ilustrar, ao
+ invés de utilizar Synopsis: o
+ portupgrade está quebrado, veja o
+ quão mais claro e mais eficiente seria
+ utilizar Synopsis: port sysutils/portupgrade
+ gerando coredumps no -current. (No caso de um
+ port, é especialmente útil ter a categoria
+ e o nome do port na linha de sinopse.)
+
+
+
+ Se você possui um patch,
+ mencione-o. Um PR que inclui um
+ patch é muito mais
+ provável de ser analisado do que um sem. Se
+ você estiver incluindo um, coloque a palavra
+ [patch] no inicio da linha
+ de sinopse. (Embora não seja obrigatório
+ utilizar exatamente esta palavra, por
+ convenção, é ela que é
+ utilizada.)
+
+
+
+ Se você é um
+ maintainer (mantenedor),
+ diga-o. Se você está mantendo uma
+ parte do código fonte (por exemplo, um port),
+ você deve considerar a possibilidade de incluir as
+ palavras [maintainer update] (incluindo
+ os colchetes) no inicio da linha de sinópse e
+ deve definir a class
+ (classe) do seu PR para maintainer-update. Desta forma
+ qualquer committer que manusear o seu
+ PR não terá de verificar o
+ Makefile do port, para certificar-se
+ de que a atualização foi enviada pelo
+ maintainer.
+
+
+
+ Seja específico. Quanto
+ mais informações você fornecer sobre o
+ problema que você está tendo, melhores
+ serão as suas chances de obter uma resposta.
+
+
+
+ Inclua a versão do &os; que você
+ está utilizando (existe um lugar para colocar
+ esta informação, veja abaixo) e em qual
+ arquitetura. Você incluir a
+ informação se está executando a
+ partir de um Release (e.g. de um CDROM ou Download),
+ ou a partir de um sistema mantido com o &man.cvsup.1;
+ (e neste caso, quando foi atualizado pela ultima
+ vez). Se você estiver utilizando o
+ &os.current;, esta vai ser a primeira coisa que
+ alguém irá lhe perguntar, porque as
+ correções (especialmente para os
+ problemas de alto nível) tendem a serem
+ realizadas muito rapidamente, e espera-se que os
+ usuários do &os.current; mantenham-se
+ atualizados.
+
+
+
+ Inclua quais opções globais
+ você especificou no seu
+ make.conf.
+ Observação: É conhecido que
+ utilizar -O2 (e acima disso) com o
+ &man.gcc.1; gera problemas em muitas
+ situações. Apesar dos desenvolvedores
+ do &os; aceitarem patches, eles normalmente não
+ estão dispostos a investigar este tipo de
+ problema por uma simples falta de tempo e de
+ voluntários, e ao invés disso podem
+ responder apenas que isto não é
+ suportado.
+
+
+
+ Se o problema pode ser reproduzido facilmente,
+ inclua informações para possibilitar
+ que ele seja reproduzido pelos desenvolvedores. Se
+ o problema só pode ser
+ demonstrado com a entrada de um conjunto de dados
+ específico, você deverá incluir um
+ exemplo destas informações, além
+ de informar qual é resultado
+ atual (errado) e qual era o resultado esperado
+ (correto). Se o conjunto de dados for muito grande ou
+ se o mesmo não puder ser tornado
+ público, tente criar um arquivo com o
+ mínimo
+ de informações necessárias para
+ replicar o problema, e que possa ser incluído
+ no seu PR.
+
+
+
+
+ Se for um problema com o kernel, esteja preparado para
+ fornecer as seguintes informações
+ (Você não precisa fornecer estas
+ informações por padrão, o que
+ só tende a encher o banco de dados, mas
+ você deve incluir os trechos acreditar que
+ são relevantes):
+
+
+ A configuração do seu kernel
+ (incluindo quais dispositivos de hardware
+ você tem instalados)
+
+
+ Se você tem ou não
+ opções de depuração
+ habilitadas (tais como
+ WITNESS), e em caso afirmativo,
+ se o problema continua ocorrendo quando
+ você altera a lógica de
+ configuração destas
+ opções
+
+
+ O texto completo de qualquer
+ backtrace,
+ panic e outras
+ mensagens no console, ou os registros do
+ /var/log/messages, caso tenha
+ sido gerado algum
+
+
+ A saída do pciconf
+ -l e as partes relevantes da
+ saída do dmesg se o
+ problema estiver relacionado a um componente de
+ hardware
+
+
+ O fato de que você leu o
+ src/UPDATING e que o seu
+ problema não está listado ali
+ (é certeza que alguém vai
+ perguntar)
+
+
+ Se você consegue ou não executar
+ outro kernel (Isto é para poder descartar a
+ possibilidade de ser um problema de hardware tais
+ como falha nos discos rígidos e
+ superaquecimento dos processadores, cujos
+ sintomas podem se confundir com problemas no
+ kernel)
+
+
+
+
+
+ Se for um problema com um port, esteja preparado
+ para fornecer as seguintes informações
+ (Você não precisa fornecer estas
+ informações por padrão, o que
+ só tende a encher o banco de dados, mas
+ você deve incluir os trechos acreditar que
+ são relevantes):
+
+
+
+ Quais ports você tem instalados
+
+
+ As variáveis de ambiente que substituem
+ os padrões do
+ bsd.port.mk, como por exemplo
+ PORTSDIR
+
+
+ O fato de que você leu o
+ ports/UPDATING e que o seu
+ problema não está listado ali
+ (é certeza que alguém vai
+ perguntar)
+
+
+
+
+
+
+
+
+
+ Evite pedidos vagos de novas
+ funcionalidades. Os PRs no formato
+ alguém realmente deveria implementar algo
+ que faz isso e aquilo são menos
+ prováveis de obterem uma resposta do
+ que os que são mais específicos. Lembre-se,
+ o código está disponível para todos,
+ de forma que se você deseja uma nova funcionalidade,
+ a melhor maneira de ter certeza de que ela
+ será incluída é começar a
+ trabalhar! Também considere o fato de que
+ muitas destas sugestões fariam mais sentido
+ como um tópico de discussão na
+ freebsd-questions do que
+ como uma entrada no banco de dados de PRs, como
+ discutido acima.
+
+
+
+ Certifique-se de que ninguém tenha
+ submetido um PR semelhante antes. Embora isso
+ já tenha sido mencionado anteriormente, faz sentido
+ repetir aqui. Esta verificação irá
+ lhe tomar apenas 1 ou 2 minutos no uso do
+ mecanismo de busca do banco de dados de PRs.
+ (é claro, todos são culpados de já
+ terem esquecido de fazer isso de uma vez ou outra.)
+
+
+
+
+ Relate apenas um problema em cada
+ relatório. Evite incluir dois ou mais
+ problemas em um mesmo relatório caso eles
+ não estejam relacionados. Quando
+ você submeter um patch, evite
+ adicionar várias funcionalidades ou corrigir
+ vários bugs em um mesmo PR, a menos que eles
+ sejam estritamente relacionados — Este tipo de
+ PR muitas vezes demanda mais tempo para ser
+ resolvido.
+
+
+
+ Evite solicitações
+ polêmicas. Se o seu PR está
+ relacionado a um tema que foi polêmico no passado,
+ você deve estar preparado para não somente
+ disponibilizar um patch, como
+ também para defender porque o seu
+ patch é a coisa certa a
+ se fazer. Como mencionado acima, realizar uma
+ busca cuidadosa no histórico das listas
+ de discussão é sempre uma boa
+ forma de se preparar.
+
+
+
+ Seja educado. Praticamente
+ todas as pessoas que potencialmente podem trabalhar no
+ seu PR são voluntários. Ninguém
+ gosta de receber ordens para fazer algo que eles já
+ estão fazendo por alguma outra
+ motivação a qual não é a de
+ ganho financeiro. Esta é uma boa coisa para ter
+ sempre em mente num projeto de código
+ aberto.
+
+
+
+
+
+ Antes de você iniciar
+
+ Antes de executar o programa &man.send-pr.1;,
+ certifique-se que a sua variável de ambiente
+ VISUAL (ou a EDITOR se a
+ VISUAL não estiver definida)
+ está definida com seu editor preferido.
+
+ Você também deve certificar-se de que o seu
+ sistema de entrega de emails esta funcionando corretamente. O
+ &man.send-pr.1; utiliza mensagens de email para enviar e
+ rastrear um relatório de problema. Se você
+ não pode enviar mensagens de email a partir da
+ máquina na qual está executando o
+ &man.send-pr.1;, os seus relatórios de problema
+ não irão chegar até a base de dados
+ GNATS. Para maiores detalhes de como configurar o sistema de
+ email no &os;, consulte o capítulo sobre Correio
+ Eletrônico no Handbook
+ do FreeBSD.
+
+ Certifique-se de que o seu sistema de email não
+ irá alterar a formatação da mensagem ao
+ encaminhá-la para o GNATS. Qualquer
+ patch que você enviar será
+ inutilizado, caso o seu sistema de email quebre
+ automaticamente as linhas, troque
+ tabulações por espaços em branco ou
+ altere os caracteres de mudança para uma nova linha,
+ etc. Entretanto, para as seções de texto
+ nós pedimos que você quebre manualmente as linhas
+ próximo dos 70 caracteres, desta forma a versão
+ web do PR poderá ser lida melhor.
+
+ Considerações similares se aplicam se
+ você estiver utilizando o formulário web de
+ submissão de PR ao invés de utilizar o
+ &man.send-pr.1;. Observe que operações de
+ copiar-e-colar possuem seus próprios efeitos colaterais
+ na formatação do texto. Em certos casos, pode
+ ser necessário usar o &man.uuencode.1; para garantir
+ que os patches cheguem sem modificações.
+
+ Finalmente, se a sua submissão será longa,
+ você deve preparar o texto do seu
+ relatório offline, desta forma nada será
+ perdido no caso de você ter problemas quando for
+ submetê-lo. Isto pode ser um problema, em especial,
+ se você estiver utilizando o formulário
+ web.
+
+
+
+ Anexando patches ou arquivos
+
+ As instruções abaixo se aplicam ao envio
+ de PRs por email:
+
+ O programa &man.send-pr.1; tem a capacidade de anexar
+ arquivos em um relatório de problemas. Você
+ pode anexar quantos arquivos desejar desde que os mesmos
+ possuam nomes únicos (i.e. o nome próprio do
+ arquivo, sem o caminho de diretório). Basta usar a
+ opção na linha de comando
+ para anexar os arquivos desejados:
+
+&prompt.user; send-pr -a /var/run/dmesg -a /tmp/errors
+
+ Não se preocupe com os arquivos binários,
+ eles serão encodados automaticamente de forma a
+ não perturbar o seu agente de correio.
+
+ Se você anexar um patch, tenha
+ certeza de utilizar a opção
+ ou no &man.diff.1; para criar um diff
+ contextual ou um diff unificado (o formato unificado é
+ preferido), e tenha certeza de especificar os números
+ de revisão exatos dos arquivos que você
+ modificou, desta forma o desenvolvedor que ler seu
+ relatório terá condições de
+ aplicá-los facilmente. Para problemas com o kernel ou
+ com os aplicativos do sistema base, um
+ patch para o &os.current; (o ramo HEAD do
+ CVS) é preferido uma vez que todo novo código
+ deve ser aplicado e testado primeiro nele. Depois que forem
+ realizados os testes apropriados, o código será
+ fundido ou migrado para o ramo &os.stable;.
+
+ Se você juntar um patch
+ no corpo do email, em vez de enviá-lo como um
+ arquivo anexo, você estará sujeito a
+ ocorrência de um problema bastante comum ocasionado
+ pela tendência de alguns clientes de email de converter
+ tabs em espaços, o que irá arruinar
+ completamente qualquer coisa que você tenha enviado
+ com intenção de que fosse parte de um
+ Makefile.
+
+ Não envie patches como anexos
+ usando Content-Transfer-Encoding: quoted-printable
+ . Isto irá realizar
+ character escaping e o
+ patch inteiro estará
+ inutilizado.
+
+ Observe também que incluir pequenos
+ patches em um PR é normalmente a
+ coisa certa a se fazer — particularmente quando ele
+ corrige o problema descrito no PR — grandes
+ patches e especialmente código novo,
+ que normalmente requerem uma revisão substancial antes
+ de serem incorporados, devem ser colocados em um servidor web
+ ou de FTP, e a url deve ser incluída no PR ao
+ invés do patch propriamente dito.
+ Os patches dentro de um email tendem a se
+ deformar, especialmente quando o GNATS está envolvido,
+ e quanto maior o patch, maior é a dificuldade para
+ ambas as partes em consertá-lo. Além de que, ao
+ colocar o patch na web, você pode
+ modificá-lo sem ter que reenviar o arquivo completo
+ como um followup do PR original.
+ Além disso, os grandes patches
+ simplesmente aumentam o tamanho do banco de dados, uma vez que
+ os relatórios de problema fechados não
+ são deletados, continuando a existir marcados como
+ closed.
+
+ Você deve observar que a menos que
+ especifique explicitamente no seu PR ou diretamente no seu
+ patch, qualquer correção que você envie
+ será considerada como estando licenciada sob os mesmos
+ termos do arquivo original que você modificou.
+
+
+
+ Preenchendo o template
+
+ As instruções abaixo se aplicam apenas ao
+ envio de PRs por email:
+
+ Quando você executar o programa &man.send-pr.1;,
+ você será apresentado a um template. O template
+ consiste em uma lista de campos, alguns dos quais
+ estarão pré-preenchidos, e alguns irão
+ possuir comentários explicando o seu propósito
+ ou então listando os valores aceitáveis.
+ Não se preocupe com os comentários, eles
+ serão removidos automaticamente se você
+ não modificá-los ou então os remova
+ você mesmo.
+
+ Na parte superior do template, logo abaixo das linhas
+ SEND-PR:, está o cabeçalho do
+ email. Você normalmente não necessita
+ modificá-lo, a menos que você esteja enviando o
+ relatório de problema a partir de uma máquina ou
+ de uma conta a qual pode enviar, mas não pode receber
+ emails, neste caso você deve configurar manualmente os
+ campos From: e Reply-To:
+ para o seu endereço de email real. Você
+ também pode querer enviar uma cópia do
+ relatório para você mesmo (ou para alguma outra
+ pessoa) através do uso de uma cópia carbono,
+ adicionando um ou mais endereços de email na linha de
+ cabeçalho Cc:.
+
+ No template do email você irá encontrar os
+ dois seguintes campos de linha única:
+
+
+
+ Submitter-Id: Não altere
+ este campo. O valor padrão é
+ current-users e está correto,
+ mesmo se você estiver executando o
+ &os.stable;.
+
+
+
+ Confidential: Não altere
+ este campo. O valor padrão é
+ no. Não tem sentido
+ alterá-lo já que não existem
+ relatórios de problema confidenciais no &os;
+ — o banco de dados de PR é
+ distribuído mundialmente pelo
+ CVSup.
+
+
+
+
+ A próxima seção descreve os campos
+ que são comuns entre a interface por email e a
+ interface web:
+
+
+
+
+ Originator:
+ Por favor informe seu nome completo, seguido opcionalmente
+ pelo seu endereço de email entre colchetes.
+ Na interface de email, este campo é normalmente
+ pré-preenchido com o campo
+ gecos do usuário com o qual
+ você está atualmente logado.
+
+
+ O endereço de email que você utilizar
+ irá se tornar uma informação
+ pública e pode vir a se tornar disponível
+ para spammers. Você deverá ter um sistema
+ antispam funcional ou então deverá
+ utilizar uma conta temporária de email.
+ Contudo, por favor, lembre-se que se você
+ não utilizar uma conta de email válida,
+ nós não seremos capazes de entrar em
+ contato com você para fazer perguntas sobre o
+ seu PR.
+
+
+
+
+
+ Organization: Campo livre para
+ o que você quiser colocar. Este campo não
+ é utilizado para nada significativo.
+
+
+
+ Synopsis: Preencha este campo com
+ uma descrição curta e precisa sobre o seu
+ problema. A synopsis é
+ utilizada como o assunto do email do relatório de
+ problema, e também é utilizada na listagem
+ de relatório de problemas e resumos;
+ relatórios de problema com
+ synopses obscuras tendem a serem
+ ignorados.
+
+ Como mencionado acima, se o seu relatório de
+ problema inclui um patch, por favor,
+ inicie sua synopsis com
+ [patch] (incluindo os colchetes); se
+ você for um maintainer considere
+ adicionar [maintainer update]
+ (incluindo os colchetes) ao início da sua
+ synopsis e defina a
+ classe do seu PR para
+ maintainer-update.
+
+
+
+ Severity: Escolha uma
+ opção entre non-critical,
+ serious ou
+ critical. Não faça
+ escândalo; abstenha-se de rotular seu problema como
+ critical a menos que ele realmente seja
+ (por ex. questões de corrupção de
+ dados, grave retrocesso de funcionalidade no -CURRENT em
+ relação a versão anterior, etc)ou de
+ serious a menos que seja algo que vai
+ afetar muitos usuários (Kernel panic ou travamentos
+ do sistema; Problemas com algum driver de dispositivo em
+ particular ou com utilitários de sistema). Os
+ desenvolvedores do &os; não irão
+ necessariamente trabalhar no seu problema mais
+ rápido se você inflar sua importância
+ uma vez que existem muitas outras pessoas que fizeram
+ exatamente isso — na verdade, alguns desenvolvedores
+ prestam pouca atenção a este campo por causa
+ disso.
+
+
+ Os grandes problemas de segurança
*** DIFF OUTPUT TRUNCATED AT 1000 LINES ***
From owner-svn-doc-head@FreeBSD.ORG Wed Sep 5 05:42:35 2012
Return-Path:
Delivered-To: svn-doc-head@freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52])
by hub.freebsd.org (Postfix) with ESMTP id 7B918106566B;
Wed, 5 Sep 2012 05:42:35 +0000 (UTC)
(envelope-from gabor@FreeBSD.org)
Received: from svn.freebsd.org (svn.freebsd.org [IPv6:2001:4f8:fff6::2c])
by mx1.freebsd.org (Postfix) with ESMTP id 648F78FC16;
Wed, 5 Sep 2012 05:42:35 +0000 (UTC)
Received: from svn.freebsd.org (localhost [127.0.0.1])
by svn.freebsd.org (8.14.4/8.14.4) with ESMTP id q855gZCs082258;
Wed, 5 Sep 2012 05:42:35 GMT (envelope-from gabor@svn.freebsd.org)
Received: (from gabor@localhost)
by svn.freebsd.org (8.14.4/8.14.4/Submit) id q855gZgf082253;
Wed, 5 Sep 2012 05:42:35 GMT (envelope-from gabor@svn.freebsd.org)
Message-Id: <201209050542.q855gZgf082253@svn.freebsd.org>
From: Gabor Kovesdan
Date: Wed, 5 Sep 2012 05:42:35 +0000 (UTC)
To: doc-committers@freebsd.org, svn-doc-all@freebsd.org,
svn-doc-head@freebsd.org
X-SVN-Group: doc-head
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Cc:
Subject: svn commit: r39504 - in head/pt_BR.ISO8859-1/articles: .
explaining-bsd
X-BeenThere: svn-doc-head@freebsd.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: SVN commit messages for the doc tree for head
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Wed, 05 Sep 2012 05:42:35 -0000
Author: gabor
Date: Wed Sep 5 05:42:34 2012
New Revision: 39504
URL: http://svn.freebsd.org/changeset/doc/39504
Log:
- Add new Brazilian Portuguese translation of the explaining-bsd article
PR: docs/170681
Submitted by: Edson Brandi
Obtained from: The FreeBSD Brazilian Portuguese Documentation Project
(http://doc.fug.com.br)
Added:
head/pt_BR.ISO8859-1/articles/explaining-bsd/
head/pt_BR.ISO8859-1/articles/explaining-bsd/Makefile (contents, props changed)
head/pt_BR.ISO8859-1/articles/explaining-bsd/article.sgml (contents, props changed)
Modified:
head/pt_BR.ISO8859-1/articles/Makefile
Modified: head/pt_BR.ISO8859-1/articles/Makefile
==============================================================================
--- head/pt_BR.ISO8859-1/articles/Makefile Wed Sep 5 05:38:11 2012 (r39503)
+++ head/pt_BR.ISO8859-1/articles/Makefile Wed Sep 5 05:42:34 2012 (r39504)
@@ -10,6 +10,7 @@
SUBDIR =
SUBDIR+= contributing
+SUBDIR+= explaining-bsd
SUBDIR+= linux-users
SUBDIR+= problem-reports
Added: head/pt_BR.ISO8859-1/articles/explaining-bsd/Makefile
==============================================================================
--- /dev/null 00:00:00 1970 (empty, because file is newly added)
+++ head/pt_BR.ISO8859-1/articles/explaining-bsd/Makefile Wed Sep 5 05:42:34 2012 (r39504)
@@ -0,0 +1,26 @@
+#
+# The FreeBSD Documentation Project
+# The FreeBSD Brazilian Portuguese Documentation Project
+#
+# $FreeBSD$
+#
+# Original revision: r38826
+#
+# Article: Explaining BSD
+
+MAINTAINER=doc@FreeBSD.org
+
+DOC?= article
+
+FORMATS?= html html-split
+WITH_ARTICLE_TOC?= YES
+
+INSTALL_COMPRESSED?= gz
+INSTALL_ONLY_COMPRESSED?=
+
+SRCS= article.sgml
+
+URL_RELPREFIX?= ../../../..
+DOC_PREFIX?= ${.CURDIR}/../../..
+
+.include "${DOC_PREFIX}/share/mk/doc.project.mk"
Added: head/pt_BR.ISO8859-1/articles/explaining-bsd/article.sgml
==============================================================================
--- /dev/null 00:00:00 1970 (empty, because file is newly added)
+++ head/pt_BR.ISO8859-1/articles/explaining-bsd/article.sgml Wed Sep 5 05:42:34 2012 (r39504)
@@ -0,0 +1,750 @@
+
+
+
+%articles.ent;
+]>
+
+
+
+ Explicando o BSD
+
+
+ Greg
+
+ Lehey
+
+
+ grog@FreeBSD.org
+
+
+
+
+ No mundo do open source, a palavra Linux
+ é quase um sinônimo de Sistema
+ Operacional, mas esse não é o
+ único sistema operacional &unix;
+ de código aberto. De acordo com o
+ Contador de Sistemas Operacionais da Internet, em
+ Abril de 1999 31.3% das máquinas conectadas na rede
+ rodam Linux. 14.6% rodam BSD &unix;. Alguns dos
+ responsáveis pelas maiores operações da
+ rede no mundo, como o Yahoo!, rodam BSD. O
+ servidor FTP mais requisitado do mundo em 1999 (atualmente
+ extinto), ftp.cdrom.com, usava BSD
+ para transferir 1.4 TB de dados por dia. É claro, que
+ não se trata de um nicho de mercado: O BSD é um
+ segredo muito bem guardado.
+
+ Então, qual é o segredo? Por que o BSD
+ não é melhor difundido, mais conhecido? Esse
+ documento abordará essas e outras
+ questões.
+
+ Ao longo desse documento, as diferenças entre o BSD
+ e o Linux serão denotadas dessa
+ forma.
+
+
+
+
+ O que é BSD?
+
+ BSD significa Distribuição do Sistema
+ de Berkeley. É o nome da
+ distribuição de códigos fonte proveniente
+ da Universidade da Califórnia, Berkeley, as quais foram
+ originalmente extensões para o sistema operacional &unix;
+ do departamento de Pesquisas da AT&T. Vários
+ projetos de sistemas operacionais de código aberto
+ são baseados em uma distribuição desse
+ código fonte, conhecido como 4.4BSD-Lite. Em
+ adição, tais sistemas constituem-se de
+ várias porções de outros projetos de
+ Código Aberto, incluindo o notável projeto GNU. A
+ constituição total do sistema operacional
+ inclui:
+
+
+
+ O kernel BSD, que cuida do agendamento de processos,
+ gerenciamento de memória, multi-processamento
+ simétrico (SMP), dispositivos de controle,
+ etc.
+
+ Ao contrário do kernel do Linux,
+ existem vários kernels distintos de sistemas BSD
+ com diferentes características e
+ recursos.
+
+
+
+ A biblioteca C, a API base do sistema.
+
+ A biblioteca C do BSD é baseada em
+ código proveniente de Berkeley, e não do
+ projeto GNU.
+
+
+
+ Programas utilitários como shells,
+ utilitários de manuseio de arquivos, compiladores,
+ linkadores.
+
+ Alguns desses programas são derivados
+ do projeto GNU, outros não.
+
+
+
+ O sistema X Window, que provê uma interface
+ gráfica.
+
+ O sistema X Window usado na maioria das versões
+ do BSD é mantido pelo
+ projeto X.Org. O &os; permite ao usuário
+ escolher entre uma variedade de ambientes de desktop, tais
+ como Gnome,
+ KDE, ou
+ Xfce; e gerenciadores de janela
+ leves como o Openbox,
+ Fluxbox, ou
+ Awesome.
+
+
+
+ Muitos outros programas e utilitários.
+
+
+
+
+
+ O que é um UNIX de verdade?
+
+ Os sistemas operacionais BSD não são clones,
+ mas sim, código livre derivado diretamente do sistema
+ operacional &unix; da AT&T, que também é o
+ ancestral dos modernos &unix; System V. Talvez isso lhe
+ surpreenda. Como pode ser isso, se a AT&T nunca
+ disponibilizou seus fontes como código aberto?
+
+ É verdade que o &unix; da AT&T não é
+ Open Source, e do ponto de vista da licença de direitos
+ legais, o BSD definitivamente não
+ é &unix;, mas por outro lado, a AT&T
+ importou muito código de outros projetos, especialmente
+ do Grupo de Pesquisas de Ciências Computacionais (CSRG) da
+ Universidade da Califórnia, em Berkeley, CA. Desde 1976
+ o CSRG lançava fitas magnéticas com cópias
+ de seu software, o qual era chamado de
+ Distribuição do Software de
+ Berkeley ou BSD.
+
+ As versões iniciais do BSD consistiam-se
+ fundamentalmente de programas à nível de
+ usuário, mas essa realidade mudou dramaticamente assim
+ que o CSRG fechou um contrato com a Agência de Pesquisas e
+ Projetos de Avançados de Defesa (a DARPA) para atualizar
+ os protocolos de comunicação que eram usados em
+ sua rede, a ARPANET. Os novos protocolos passaram a ser
+ conhecidos como Protocolos de Internet, e
+ mais tarde como TCP/IP se tornando os mais
+ importantes protocolos de todos os tempos. A primeira
+ implementação amplamente distribuída desses
+ protocolos eram parte do 4.2BSD, em 1982.
+
+ Ao longo da década de 80, várias empresas que
+ produziam estações de trabalho começaram a
+ se espalhar. Muitas delas preferiam licenciar o &unix; ao
+ invés de desenvolverem sistemas operacionais por si
+ mesmas. A Sun Microsystems em particular, licenciou o &unix; e
+ implementou uma versão do 4.2BSD, a qual eles chamaram de
+ &sunos;. Quando a AT&T se deu permissão para vender
+ o &unix; comercialmente, começaram a desenvolver uma
+ implementação “na unha” chamada de
+ System III, que seria rapidamente sucedida pelo System V. A
+ base do código do System V não incluía o suporte a
+ networking, então todas as implementações
+ passaram a incluir software adicional do BSD, incluindo o
+ TCP/IP, e também programas utilitários como o
+ interpretador de linha de comandos csh e o
+ editor vi. Em sua coletividade, estes
+ aprimoramentos foram conhecidos como
+ Extensões de Berkeley.
+
+ As fitas magnéticas do BSD continham código
+ fonte da AT&T e por isso precisavam de uma licença de
+ fontes do &unix;. Por volta de 1990, os fundos do CSRG estavam
+ acabando. Alguns membros do grupo decidiram lançar o
+ código BSD, que era Open Source, sem o código
+ proprietário da AT&T. Finalmente isso aconteceu com
+ o Networking Tape 2, normalmente conhecido
+ como Net/2. O Net/2 não era um
+ sistema operacional completo: aproximadamente 20% do
+ código do kernel estava faltando. Um dos membros do
+ CSRG, William F. Jolitz, escreveu o código que faltava e
+ o lançou em 1992, como o 386BSD. Ao
+ mesmo tempo, um outro grupo de membros do extinto CSRG formou
+ uma empresa comercial chamada de Berkeley Software Design
+ Inc. e lançou uma versão beta de seu
+ sistema operacional, chamada de BSD/386, baseado nos mesmos
+ fontes. Depois o nome do sistema operacional mudou para
+ BSD/OS.
+
+ O 386BSD nunca se tornou um sistema operacional
+ estável. Ao invés disso, outros dois projetos
+ nasceram à partir dele, em 1993: O NetBSD e o FreeBSD. Originalmente
+ os dois projetos divergiram devido às diferenças
+ quanto à paciência na espera de novas melhorias no
+ 386BSD: o pessoal do NetBSD começou o projeto no
+ início do ano, e a primeira versão do FreeBSD
+ não ficou pronta até o final do ano. No meio
+ tempo, a base do código se modificou o suficiente para
+ tornar difícil uma união. Em
+ adição, os projetos tinham objetivos diferentes,
+ como veremos a seguir. Em 1996, um projeto posterior, o OpenBSD, originou-se
+ à partir do NetBSD e em 2003, o DragonFlyBSD
+ originou-se a partir do FreeBSD.
+
+
+
+ Por quê o BSD não é mais
+ conhecido?
+
+ Por algumas razões, o BSD é relativamente
+ desconhecido:
+
+
+
+ Os desenvolvedores do BSD estão frequentemente
+ mais interessados em aprimorar seu código do que
+ fazer propaganda dele.
+
+
+
+ A maior parte da popularidade do Linux se deve a fatores
+ externos ao projeto Linux, como a imprensa, e companhias
+ criadas para oferecer serviços em Linux. Até
+ recentemente, os BSDs open source não contavam com
+ tais proponentes.
+
+
+
+ Os desenvolvedores BSD tendem a ser mais experientes do
+ que desenvolvedores Linux, e tem menos interesse em tornar o
+ sistema fácil de utilizar. Novatos tendem a se
+ sentir mais confortáveis com Linux.
+
+
+
+ Em 1992, a AT&T processou a BSDI, vendedora do
+ BSD/386, alegando que o produto continha código
+ proprietário da AT&T. O caso foi resolvido na
+ corte, em 1994, mas os aspectos da litigação
+ continuam perseguindo as pessoas. Em Março de 2000
+ um artigo publicado na rede afirmou que o caso havia sido
+ resolvido recentemente.
+
+
+ Um detalhe que o processo judicial clarificou foi sobre a
+ denominação: nos anos 80, os BSD eram
+ conhecidos como BSD &unix;. Com a
+ eliminação do último vestígio de
+ código da AT&T no BSD, ele também perdeu o
+ direito de ser chamado de &unix; Contudo ainda podem ser
+ vistas referências em títulos de livros como
+ the 4.3BSD &unix; operating system e
+ the 4.4BSD operating system.
+
+
+
+ Existe uma idéia que os projetos BSD sejam
+ fragmentados e beligerantes. O Wall
+ Street Journal falou de
+ balkanização nos projetos BSD.
+ Assim como o processo judicial, essas idéias se
+ baseiam fundamentalmente em história antiga.
+
+
+
+
+
+ Comparando BSD e Linux
+
+ Então qual é realmente a diferença
+ entre, digamos, o Debian Linux e o FreeBSD? Pra maioria dos
+ usuários, as diferenças são
+ surpreendentemente pequenas: Ambos são sistemas
+ operacionais &unix; like. Ambos são desenvolvidos por
+ projetos não comerciais (é claro que isso
+ não se aplica a muitas outras distribuições
+ Linux). Na próxima seção, vamos dar uma
+ olhada no BSD e compará-lo com o Linux. As
+ descrições se aplicam mais ao FreeBSD, que
+ somatiza uma média estimada de 80% das
+ instalações de sistemas BSD, mas as
+ diferenças pro NetBSD, pro OpenBSD e pro DragonFlyBSD
+ são pequenas.
+
+
+ Quem é dono do BSD?
+
+ Nenhuma pessoa ou corporação é dona
+ do BSD. Ele é criado e distribuído por uma
+ comunidade de contribuidores altamente técnicos em todo
+ o mundo. Alguns dos componentes do BSD são projetos
+ Open Source independentes e gerenciados por mantenedores de
+ projetos distintos.
+
+
+
+ Como o BSD é desenvolvido e atualizado?
+
+ Os kernels do BSD são desenvolvidos e mantidos
+ seguindo o modelo de desenvolvimento do Open Source. Cada
+ projeto mantém uma árvore de
+ código fonte publicamente acessível
+ sob o Sistema de
+ Versões Concorrentes (CVS), que contém
+ todos os arquivos fontes do projeto, incluindo
+ documentação e outros arquivos acidentais. O
+ CVS permite que usuários façam check
+ out (em outras palavras, extrair uma cópia)
+ de qualquer versão desejada do sistema.
+
+ Um grande número de desenvolvedores ao redor do
+ mundo contribui para as melhorias do BSD. Eles são
+ divididos em 3 tipos:
+
+
+
+ Contribuidores escrevem
+ código e documentação. Eles
+ não têm permissão de commit (adicionar
+ código) diretamente na árvore de
+ código fonte. Para que seu código seja
+ incluso no sistema, é necessário que seja
+ revisado e aprovado por um desenvolvedor registrado, os
+ quais são conhecidos como
+ committer.
+
+
+
+ Committers são
+ desenvolvedores com acesso de escrita na árvore do
+ código fonte. Para se tornar um commiter, o
+ indivíduo deve mostrar habilidade na área em
+ que ele é ativo.
+
+ Faz parte da responsabilidade individual de cada
+ desenvolvedor considerar quando devem obter
+ autorização antes de fazer um commit na
+ árvore. No geral, desenvolvedores experientes
+ podem fazer modificações que são
+ obviamente corretas sem precisar de consenso. Por
+ exemplo, um commiter do projeto de
+ documentação pode corrigir erros
+ tipográficos ou gramaticais sem a
+ necessidade de uma revisão. Por outro lado,
+ espera-se que desenvolvedores que fazem
+ alterações muito abrangentes ou complicadas
+ enviem suas mudanças para revisão antes de
+ adicioná-las. Em casos extremos, um membro do
+ Grupo Central (Core Team) cuja função seja,
+ o Arquiteto Principal pode ordenar que as
+ modificações sejam retiradas da
+ árvore do código fonte, em um processo
+ conhecido como backing out. Todos
+ os desenvolvedores recebem mensagens de correio
+ eletrônico sobre cada alteração
+ individual, portanto é impossível fazer
+ alguma modificação secretamente.
+
+
+
+ O Grupo Central. O FreeBSD e o
+ NetBSD cada qual, tem um grupo central que gerencia o
+ projeto. Tais grupos centrais foram criados no decorrer
+ dos projetos e seu papel não é sempre bem
+ definido. Não é preciso ser um
+ desenvolvedor para se tornar membro do grupo central,
+ apesar de que, normalmente esse é o caso. As
+ regras para o grupo central variam de um projeto para o
+ outro, mas no geral eles têm mais voz na hora de dizer as
+ direções que o projeto deve seguir, do que
+ outros membros fora do grupo.
+
+
+
+ Esse modelo se diferencia do Linux em inúmeras
+ maneiras:
+
+
+
+ Não existe uma pessoa em especial que controla
+ o conteúdo do sistema. Na prática, essa
+ diferença é sobretaxada, considerando que o
+ Arquiteto Principal pode solicitar que códigos
+ sejam retirados do sistema, e que até mesmo o
+ projeto Linux tem várias pessoas autorizadas a
+ fazer modificações.
+
+
+
+ Por outro lado, existe um
+ repositório central, um lugar único onde os
+ fontes inteiros do sistema operacional podem ser
+ encontrados, incluindo todas as versões
+ anteriores.
+
+
+
+ Os projetos BSD mantém um Sistema
+ Operacional completo, não apenas o
+ kernel. Essa distinção é
+ marginalmente proveitosa: nem o BSD nem o Linux são
+ úteis sem aplicações. As
+ aplicações usadas sob BSD são
+ frequentemente as mesmas aplicações usadas
+ sob Linux.
+
+
+
+ Como resultado da manutenção formalizada
+ de uma única árvore CVS do código
+ fonte, o desenvolvimento do BSD é limpo, e é
+ possível acessar qualquer versão do sistema
+ por seu número de lançamento (release) ou
+ por data. O CVS ainda oferece manutenção
+ incremental ao sistema: por exemplo, o repositório
+ do FreeBSD é atualizado em média 100 vezes
+ por dia. A maioria dessas alterações
+ é de pequena ordem.
+
+
+
+
+
+ Releases BSD
+
+ O FreeBSD, o NetBSD e o OpenBSD oferecem o sistema em
+ três versões (releases)
+ diferentes. Como no Linux, os releases são
+ identificados por um número, como 1.4.1 ou 3.5. Em
+ adição, o número da versão tem
+ um sufixo, indicando seu propósito:
+
+
+
+ A versão de desenvolvimento do sistema é
+ chamada de CURRENT. O FreeBSD
+ relaciona um número ao CURRENT, por exemplo, FreeBSD
+ 5.0-CURRENT. O NetBSD usa um esquema de
+ denominação um pouco diferente, adicionando
+ um sufixo com uma letra única que indica
+ modificações nas interfaces internas, por
+ exemplo NetBSD 1.4.3G. O OpenBSD não adiciona
+ números (OpenBSD-current). Todo
+ novo desenvolvimento no sistema vai nesse branch.
+
+
+
+ Em intervalos regulares, entre duas a quatro vezes por
+ ano, os projetos lançam uma nova versão de
+ RELEASE do sistema, que é
+ disponibilizado em CD-ROM e por download gratuíto
+ em sítios de FTP, por exemplo OpenBSD 2.6-RELEASE
+ ou NetBSD 1.4-RELEASE. A versão do RELEASE
+ é destinada a usuários finais e é a
+ versão normal do sistema. O NetBSD oferece ainda
+ patch releases (releases de
+ correções) com um terceiro dígito,
+ por exemplo, NetBSD 1.4.2.
+
+
+
+ Conforme os problemas são encontrados em uma
+ versão RELEASE, eles são corrigidos, e as
+ correções são adicionadas à
+ árvore CVS. No FreeBSD a versão resultante
+ é chamada de STABLE,
+ enquanto que no NetBSD e no OpenBSD elas continuam sendo
+ chamadas de versão RELEASE. Novas
+ características menores também podem ser
+ adicionadas nesse branch depois do período de
+ testes no CURRENT.
+
+
+
+ Em contraste, o Linux mantém duas
+ árvores de código separadas: a versão
+ estável e a versão de desenvolvimento. A
+ versão estável tem ainda um número
+ menor de versão, como 2.0, 2.2 ou 2.4. Versões
+ em desenvolvimento tem o número menor ímpar,
+ como 2.1, 2.4 e 2.5. Em cada caso, a versão é
+ ainda seguida de um número posterior designando o
+ release exato. Em adição, cada vendedor de
+ Linux coloca suas próprias aplicações e
+ utilitários à nível de usuário,
+ portanto o nome de sua distribuição
+ também é importante. Cada
+ distribuição do vendedor ainda é
+ acrescida de seu próprio número, então
+ a descrição completa seria algo parecido com
+ TurboLinux 6.0 com kernel
+ 2.2.14
+
+
+
+ Quais são as versões disponíveis do
+ BSD?
+
+ Em contraste com as numerosas distribuições
+ Linux, existem apenas quatro BSDs de código livre.
+ Cada projeto BSD mantém sua própria
+ árvore de código fonte e seu próprio
+ kernel. Na prática, as divergências entre o
+ código à nível de usuário parece
+ ser ainda menor entre os projetos BSD do que entre os
+ vários Linux.
+
+ É difícil categorizar os objetivos de cada
+ projeto: as diferenças são bastante subjetivas.
+ Basicamente,
+
+
+
+ O FreeBSD clama por alta performance e facilidade de
+ uso para usuários finais, e é o favorito de
+ provedores de conteúdo da rede mundial de
+ computadores. Ele pode ser usado em um grande
+ número de plataformas, incluindo sistemas baseados
+ em &i386; (PCs), sistemas baseados em
+ processadores AMD 64-bit, sistemas baseados em
+ &ultrasparc;, sistemas baseados em processadores Compaq
+ Alpha e sistemas baseados em torno da
+ especificação NEC PC-98. O projeto &os;
+ possui significativamente mais usuários do que
+ os outros projetos.
+
+
+ O NetBSD clama pelo máximo de portabilidade:
+ é lógico que roda NetBSD. Ele
+ roda de máquinas palmtop à grandes
+ servidores, e vem sendo usado até em missões
+ espaciais da NASA. É particularmente uma boa
+ escolha para rodar em equipamentos antigos que não
+ sejam &intel;.
+
+
+
+ O OpenBSD clama por segurança e pureza de
+ código: ele usa uma combinação dos
+ conceitos de código livre com rigorosas
+ revisões de seu código para criar um sistema
+ demonstravelmente correto, tornando-o a escolha de
+ organizações conscientes com a
+ segurança como bancos e departamentos do governo.
+ Como o NetBSD, ele roda em várias
+ plataformas.
+
+
+
+ O DragonFlyBSD clama por alta performance e
+ escalabilidade acima de tudo, não importa se estamos
+ falando de um sistema composto por um único nó
+ ou um sistema massivamente clusterizado. O DragonFlyBSD tem
+ muitos objetivos técnicos de longo prazo, mas o seu
+ foco concentra-se em prover uma infra estrutura de SMP
+ (multiprocessamento simétrico) que seja fácil
+ de entender, manter e desenvolver.
+
+
+
+ Existem ainda dois sistemas operacionais BSD &unix;
+ adicionais que não são de código livre,
+ o BSD/OS e o &macos; X da Apple:
+
+
+
+ O BSD/OS era o mais velho dos derivados do 4.4BSD.
+ Ele não era de código livre, embora as
+ licenças de seu código fonte estivessem
+ disponíveis por um preço relativamente
+ baixo. Ele assemelhava-se ao FreeBSD de diversas formas.
+ Dois anos depois da aquisição da BSDI pela
+ Wind River Systems, o BSD/OS falhou em sobreviver como um
+ produto independente. O suporte e o código fonte
+ podem ainda estar disponíveis pela Wind River, mas
+ os novos desenvolvimentos estão todos focados no
+ sistema operacional embarcado VxWorks.
+
+
+
+ O
+ &macos; X é a mais recente versão do
+ sistema operacional da linha &macintosh; da Apple Computers Inc.
+ O core BSD deste sistema operacional, o Darwin,
+ está disponível como um sistema operacional
+ completamente funcional para computadores x86 e PPC.
+ Contudo, o sistema gráfico Aqua/Quartz e muitos
+ outros aspectos proprietários do &macos; X
+ continuam como código fechado. Vários
+ desenvolvedores do Darwin também são
+ desenvolvedores do &os; e vice versa.
+
+
+
+
+
+ Como a licença BSD se diferencia da licença
+ Pública GNU?
+
+ O Linux está disponível sob a Licença
+ Pública Geral GPL (GPL), que foi planejada
+ para eliminar o software proprietário (de fonte
+ fechada). Em particular, qualquer trabalho derivado de um
+ produto lançado sob a GPL também deve oferecer
+ seu código fonte, caso seja requerido. Em contraste, a
+ licença
+ BSD é menos restritiva:
+ distribuições apenas binárias são
+ permitidas. Isso é particularmente atrativo para
+ aplicações acopladas (embedded).
+
+
+
+ O que mais eu deveria saber?
+
+ Considerando que um número menor de
+ aplicações está disponível para
+ o BSD do que para o Linux, os desenvolvedores do BSD criaram
+ um pacote de compatibilidade Linux, que permite que programas
+ Linux sejam executados sob BSD. O pacote inclui
+ modificações no kernel, de forma a possibilitar
+ as corretas chamadas de sistemas Linux, e arquivos de
+ compatibilidade Linux, como a biblioteca C. Não existe
+ diferença notável na velocidade de
+ execução entre aplicações Linux
+ rodando em uma máquina Linux e aplicações
+ Linux rodando em uma máquina BSD de mesma
+ velocidade.
+
+ A natureza tudo do mesmo fornecedor dos
+ sistemas BSD implica na maior facilidade de
+ atualização do que frequentemente acontece no
+ caso do Linux. Os BSD oferecem atualizações de
+ versões de bibliotecas oferecendo módulos de
+ compatibilidade com versões mais antigas de
+ bibliotecas, dessa forma é possível rodar
+ binários que existem há vários anos sem o
+ menor problema.
+
+
+
+ Qual eu devo usar, BSD ou Linux?
+
+ O que isso tudo significa na prática? Quem deve
+ usar BSD? Quem deve usar Linux?
+
+ Essa é uma pergunta muito difícil para se
+ responder. Aqui estão algumas
+ considerações:
+
+
+
+ Se não está quebrado, não
+ conserte: Se você já usa algum
+ sistema operacional de código livre, e está
+ feliz com ele, provavelmente não existe uma boa
+ razão para mudar.
+
+
+
+ Sistemas BSD, em particular o FreeBSD, podem ter
+ performance notavelmente superior ao Linux. Mas
+ isso não é uma regra. Em muitos casos a
+ diferença pode ser pouca ou até mesmo nem
+ existir. Em alguns casos o Linux pode funcionar melhor
+ que o FreeBSD.
+
+
+
+ No geral, sistemas BSD tem melhor
+ reputação por sua confiabilidade,
+ principalmente por ser resultado de uma base de
+ códigos mais madura.
+
+
+
+ Os projetos BSD têm uma melhor
+ reputação em relação a
+ qualidade e abrangência da sua
+ documentação. Os vários projetos de
+ documentação têm por objetivo prover
+ ativamente documentos atualizados, em muitos idiomas e
+ cobrindo todos os aspectos do sistema.
+
+
+
+
+ A licença BSD pode ser mais atrativa do que a
+ GPL.
+
+
+
+ O BSD pode executar a maioria dos binários do
+ Linux, enquanto o Linux não pode executar
+ binários do BSD. Muitas das
+ implementações; BSD podem inclusive executar
+ binários de outros sistemas derivados do &unix;.
+ Como resultado, o BSD pode ser uma opção de
+ migração a partir de outros sistemas mais
+ fácil do que o Linux seria.
+
+
+
+
+
+ Quem oferece suporte, serviços e treinamento para
+ o BSD?
+
+ A BSDI / FreeBSD
+ Mall, Inc. têm fornecido contratos de suporte
+ FreeBSD no mercado a quase uma década.
+
+ Em adição, cada um dos projetos tem uma
+ lista de consultores que podem ser contratados: FreeBSD,
+ NetBSD,
+ e OpenBSD.
+
+
+
From owner-svn-doc-head@FreeBSD.ORG Wed Sep 5 05:47:06 2012
Return-Path:
Delivered-To: svn-doc-head@freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34])
by hub.freebsd.org (Postfix) with ESMTP id E5594106564A;
Wed, 5 Sep 2012 05:47:06 +0000 (UTC)
(envelope-from gabor@FreeBSD.org)
Received: from svn.freebsd.org (svn.freebsd.org [IPv6:2001:4f8:fff6::2c])
by mx1.freebsd.org (Postfix) with ESMTP id CC7518FC0C;
Wed, 5 Sep 2012 05:47:06 +0000 (UTC)
Received: from svn.freebsd.org (localhost [127.0.0.1])
by svn.freebsd.org (8.14.4/8.14.4) with ESMTP id q855l6W4082923;
Wed, 5 Sep 2012 05:47:06 GMT (envelope-from gabor@svn.freebsd.org)
Received: (from gabor@localhost)
by svn.freebsd.org (8.14.4/8.14.4/Submit) id q855l6jY082918;
Wed, 5 Sep 2012 05:47:06 GMT (envelope-from gabor@svn.freebsd.org)
Message-Id: <201209050547.q855l6jY082918@svn.freebsd.org>
From: Gabor Kovesdan
Date: Wed, 5 Sep 2012 05:47:06 +0000 (UTC)
To: doc-committers@freebsd.org, svn-doc-all@freebsd.org,
svn-doc-head@freebsd.org
X-SVN-Group: doc-head
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Cc:
Subject: svn commit: r39505 - in head/pt_BR.ISO8859-1: articles
articles/freebsd-questions share/sgml
X-BeenThere: svn-doc-head@freebsd.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: SVN commit messages for the doc tree for head
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Wed, 05 Sep 2012 05:47:07 -0000
Author: gabor
Date: Wed Sep 5 05:47:06 2012
New Revision: 39505
URL: http://svn.freebsd.org/changeset/doc/39505
Log:
- Add new Brazilian Portuguese translation of the freebsd-questions article
PR: docs/170710
Submitted by: Edson Brandi
Obtained from: The FreeBSD Brazilian Portuguese Documentation Project
(http://doc.fug.com.br)
Added:
head/pt_BR.ISO8859-1/articles/freebsd-questions/
head/pt_BR.ISO8859-1/articles/freebsd-questions/Makefile (contents, props changed)
head/pt_BR.ISO8859-1/articles/freebsd-questions/article.sgml (contents, props changed)
Modified:
head/pt_BR.ISO8859-1/articles/Makefile
head/pt_BR.ISO8859-1/share/sgml/mailing-lists.ent
Modified: head/pt_BR.ISO8859-1/articles/Makefile
==============================================================================
--- head/pt_BR.ISO8859-1/articles/Makefile Wed Sep 5 05:42:34 2012 (r39504)
+++ head/pt_BR.ISO8859-1/articles/Makefile Wed Sep 5 05:47:06 2012 (r39505)
@@ -11,6 +11,7 @@
SUBDIR =
SUBDIR+= contributing
SUBDIR+= explaining-bsd
+SUBDIR+= freebsd-questions
SUBDIR+= linux-users
SUBDIR+= problem-reports
Added: head/pt_BR.ISO8859-1/articles/freebsd-questions/Makefile
==============================================================================
--- /dev/null 00:00:00 1970 (empty, because file is newly added)
+++ head/pt_BR.ISO8859-1/articles/freebsd-questions/Makefile Wed Sep 5 05:47:06 2012 (r39505)
@@ -0,0 +1,26 @@
+#
+# The FreeBSD Documentation Project
+# The FreeBSD Brazilian Portuguese Documentation Project
+#
+# $FreeBSD$
+#
+# Original revision: r38826
+#
+# Article: How to get best results from the FreeBSD-questions mailing list
+
+MAINTAINER=doc@FreeBSD.org
+
+DOC?= article
+
+FORMATS?= html html-split
+WITH_ARTICLE_TOC?= YES
+
+INSTALL_COMPRESSED?= gz
+INSTALL_ONLY_COMPRESSED?=
+
+SRCS= article.sgml
+
+URL_RELPREFIX?= ../../../..
+DOC_PREFIX?= ${.CURDIR}/../../..
+
+.include "${DOC_PREFIX}/share/mk/doc.project.mk"
Added: head/pt_BR.ISO8859-1/articles/freebsd-questions/article.sgml
==============================================================================
--- /dev/null 00:00:00 1970 (empty, because file is newly added)
+++ head/pt_BR.ISO8859-1/articles/freebsd-questions/article.sgml Wed Sep 5 05:47:06 2012 (r39505)
@@ -0,0 +1,795 @@
+
+
+
+%articles.ent;
+]>
+
+
+
+ Como obter o melhor resultado para as suas perguntas na
+ lista de discussão FreeBSD-Question
+
+
+ Greg
+ Lehey
+
+
+ grog@FreeBSD.org
+
+
+
+ $FreeBSD$
+
+
+ &tm-attrib.freebsd;
+ &tm-attrib.microsoft;
+ &tm-attrib.netscape;
+ &tm-attrib.opengroup;
+ &tm-attrib.qualcomm;
+ &tm-attrib.general;
+
+
+
+ Este documento prove informações
+ úteis para as pessoas que planejam enviar
+ um email para a lista de discussão
+ FreeBSD-questions. Os avisos e conselhos foram elaborados com
+ o com objetivo de maximizar as chances de que o leitor receba
+ respostas úteis para as suas mensagens.
+
+ Este documento é enviado regularmente para a lista
+ de discussão FreeBSD-questions.
+
+
+
+
+ Introdução
+
+ A lista de discussão
+ FreeBSD-questions é
+ mantida pelo projeto FreeBSD para ajudar as pessoas que possuem
+ perguntas referentes ao uso cotidiano do FreeBSD.
+ Diferentemente da lista FreeBSD-hackers, na
+ qual são discutidas questões mais
+ avançadas, tais como os rumos
+ a serem seguidos no desenvolvimento futuro do FreeBSD.
+
+
+ O termo hacker não está
+ relacionado com pessoas que invadem os computadores de outras
+ pessoas. O termo correto para este tipo de atividade é
+ cracker, porém a imprensa popular
+ insiste em confundi-los. Os hackers do FreeBSD desaprovam
+ fortemente as atividades de cracking
+ (quebra de segurança), e não se envolvem com
+ as mesmas. Para uma descrição mais abrangente
+ sobre hackers, consulte o artigo
+
+ Como se tornar um hacker, de autoria de Eric
+ Raymond.
+
+
+ A FreeBSD-questions se destina a ajudar tanto as pessoas
+ que buscam auxilio na lista (os
+ recém-chegados), quanto as que respondem
+ as perguntas enviadas (os hackers).
+
+ Inevitavelmente é normal ocorrerem alguns atritos
+ na lista, os quais são decorrentes dos diferentes
+ pontos de vista dos dois grupos predominantes. Os
+ recém-chegados acusam os hackers de serem arrogantes, de
+ se considerarem melhores que os outros, e de serem
+ inúteis, enquanto os hackers acusam os
+ recém-chegados de serem estúpidos, de serem
+ incapazes de lerem a documentação, e de esperarem
+ que tudo lhe seja dado em uma bandeja de prata. É claro,
+ existem elementos verdadeiros nas afirmações de
+ ambas as partes, porém estes pontos de vista, na maior
+ parte das vezes, levam ambas as partes a uma
+ sensação de frustração.
+
+ Neste documento, eu gostaria de fazer algo para aliviar
+ esta frustração e auxiliá-los para que
+ obtenham melhores resultados para as suas perguntas na
+ FreeBSD-questions. Na sessão seguinte, eu mostrarei
+ como enviar uma pergunta, e depois disso, iremos ver como
+ responder a uma.
+
+
+
+ Como se cadastrar na
+ FreeBSD-questions
+
+ A FreeBSD-questions é uma lista de discussão
+ por email, logo você precisa ter acesso a uma conta de
+ email. Para se inscrever vá até a página web de
+ informações da lista de discussão
+ FreeBSD-questions. Na seção denominada
+ Subscribing to freebsd-questions (Inscrevendo-se
+ na freebsd-question) preencha o campo Your email
+ address com o seu endereço de email; os outros
+ campos são opcionais.
+
+
+ O campo de password no formulário de
+ inscrição provê apenas uma segurança
+ leve, mas que deve evitar que outras pessoas brinquem com a sua
+ inscrição. Não utilize nenhum
+ password que você já faça uso em outros
+ serviços e/ou sites, pois eventualmente ele
+ será enviado de volta para você em texto
+ simples.
+
+
+ Você irá receber uma mensagem de
+ confirmação do mailman;
+ siga as instruções contidas no email para
+ completar a sua inscrição.
+
+ Por último, quando você receber a mensagem de
+ boas vindas (Welcome) do
+ mailman contendo os detalhes da
+ lista e o seu password para a área de assinantes,
+ por favor, salve uma cópia. Se
+ no futuro você desejar sair da lista, você
+ irá precisar destas informações.
+ Veja a próxima seção para maiores
+ detalhes.
+
+
+
+ Como se descadastrar da
+ FreeBSD-questions?
+
+ Quando você se cadastrou na FreeBSD-questions,
+ você recebeu uma mensagem de boas vindas do
+ mailman. Nesta mensagem, no meio de
+ outras coisas, estão as instruções de
+ como se descadastrar. Aqui está uma mensagem
+ típica:
+
+
+Welcome to the freebsd-questions@freebsd.org mailing list!
+
+To post to this list, send your email to:
+
+ freebsd-questions@freebsd.org
+
+General information about the mailing list is at:
+
+ http://lists.freebsd.org/mailman/listinfo/freebsd-questions
+
+If you ever want to unsubscribe or change your options (e.g., switch
+to or from digest mode, change your password, etc.), visit your
+subscription page at:
+
+http://lists.freebsd.org/mailman/options/freebsd-questions/grog%40lemsi.de
+
+You can also make such adjustments via email by sending a message to:
+
+ freebsd-questions-request@freebsd.org
+
+with the word `help' in the subject or body (don't include the
+quotes), and you will get back a message with instructions.
+
+You must know your password to change your options (including changing
+the password, itself) or to unsubscribe. It is:
+
+ 12345
+
+Normally, Mailman will remind you of your freebsd.org mailing list
+passwords once every month, although you can disable this if you
+prefer. This reminder will also include instructions on how to
+unsubscribe or change your account options. There is also a button on
+your options page that will email your current password to you.
+
+
+ A partir da url especificada na sua mensagem de boas vindas
+ (Welcome) você deve visitar a página
+ de gerenciamento de conta (Account management
+ page) e entrar com a sua requisição de
+ cancelamento da sua inscrição
+ (Unsubscribe) na lista
+ de discussão FreeBSD-questions.
+
+ Uma mensagem de confirmação será
+ enviada para você pelo mailman;
+ siga as instruções contidas nesta mensagem para
+ finalizar o processo de cancelamento.
+
+ Se você já fez isso, e ainda continua
+ recebendo mensagens da lista, envie uma mensagem para
+ freebsd-questions-request@FreeBSD.org pedindo
+ ajuda e eles irão resolver as coisas para você.
+ Não envie a sua mensagem para a
+ FreeBSD-questions: eles não podem
+ ajudá-lo.
+
+
+
+ Devo perguntar na -questions
+ ou na -hackers?
+
+ Duas listas de discussão lidam com questões
+ gerais sobre o FreeBSD, FreeBSD-questions e
+ FreeBSD-hackers. Em alguns casos, não
+ é realmente muito simples saber para qual dos grupos
+ você deve perguntar. O critério seguinte deve
+ ajuda-lo nessa decisão para 99% de todas as
+ dúvidas, entretanto:
+
+
+
+ Se a pergunta é de natureza geral, pergunte na
+ FreeBSD-questions. Exemplos de perguntas
+ desta natureza são as perguntas sobre a
+ instalação do FreeBSD ou sobre o uso
+ especifico de algum utilitário &unix;.
+
+
+
+ Se você acredita que a pergunta está
+ relacionada a uma falha, mas você não tem
+ certeza disso ou não sabe como procurá-lo,
+ envie a mensagem para a FreeBSD-questions
+ .
+
+
+
+ Se a pergunta se relaciona a uma falha, e você tem
+ certeza de que é uma falha (por
+ exemplo, você pode destacar o lugar no código
+ fonte onde ele ocorre, e você talvez tenha uma
+ correção), então envie a mensagem para
+ a FreeBSD-hackers.
+
+
+
+ Se a pergunta se relaciona a melhorias para o FreeBSD, e
+ você pode fazer sugestões sobre como
+ implementá-las, então envie a mensagem para a
+ FreeBSD-hackers.
+
+
+
+ Existe um grande número de outras listas de
+ discussão especializadas, por exemplo,
+ FreeBSD-isp, a qual trata dos interesses dos
+ ISPs (Provedores de Serviço Internet) que rodam o
+ FreeBSD. No caso de você ser um ISP, isso não
+ significa que deve enviar automaticamente suas perguntas para a
+ FreeBSD-isp. O critério acima
+ continua válido, e você deve continuar seguindo-o,
+ uma vez que você irá obter melhores resultados
+ desta forma.
+
+
+
+ Antes de enviar uma pergunta
+
+ Você pode (e deve) fazer algumas coisas você
+ mesmo antes de fazer uma pergunta em uma lista de
+ discussão:
+
+
+
+ Tente resolver o problema sozinho. Se você
+ enviar uma pergunta a qual mostre que você já
+ tentou resolver o problema, geralmente irá atrair
+ mais a atenção das pessoas que lerem a sua
+ pergunta. Além disso, ao tentar resolver o problema,
+ você irá reforçar o seu domínio
+ do FreeBSD, o que irá eventualmente possibilitar que
+ você o utilize para ajudar outras pessoas, respondendo
+ as perguntas que elas enviarem para as listas de
+ discussão.
+
+
+
+ Leia as páginas de manual, e a
+ documentação do FreeBSD (elas estão
+ instaladas em /usr/doc ou
+ acessíveis via WWW em http://www.FreeBSD.org),
+ especialmente o handbook e o
+ FAQ.
+
+
+
+ Navegue ou faça uma busca no histórico da
+ lista para ver se a sua pergunta ou uma semelhante a ela
+ já não foi feita (e possivelmente respondida)
+ antes. Você pode navegar e/ou realizar buscas no
+ histórico das listas de discussão nos URLs
+ http://www.FreeBSD.org/mail
+ e
+ http://www.FreeBSD.org/search/search.html#mailinglists
+ respectivamente. Isto também pode ser feito em
+ outros locais, como por exemplo em http://marc.theaimsgroup.com
+ .
+
+
+
+ Utilize um mecanismo de busca como o Google ou o Yahoo para procurar
+ respostas para a sua dúvida. O Google possui uma
+ interface especifica
+ para buscas relacionadas aos *BSDs.
+
+
+
+
+
+ Como enviar uma pergunta
+
+ Quando enviar uma pergunta para a FreeBSD-questions,
+ considere os seguintes pontos:
+
+
+
+ Lembre-se que ninguém é pago para
+ responder as suas perguntas sobre FreeBSD. Eles o fazem de
+ boa vontade. Você pode influenciar positivamente esta
+ boa vontade através do envio de uma pergunta bem
+ formulada fornecendo a maior quantidade possível de
+ informações relevantes. Você pode
+ influenciar de forma negativa esta boa vontade ao enviar uma
+ pergunta incompleta, ilegível ou rude. É
+ perfeitamente possível enviar uma mensagem para a
+ FreeBSD-questions e não obter nenhuma resposta mesmo
+ que você siga estas regras. Mas é muito mais
+ provável que você não obtenha a resposta
+ se você não as seguir. No restante deste
+ documento, veremos como obter o máximo de resultado
+ para as suas perguntas na FreeBSD-questions.
+
+
+
+ Nem todos que respondem as perguntas sobre FreeBSD
+ lêem todas as mensagens: Eles olham para o assunto da
+ mensagem e decidem se os interessa. Claramente, é de
+ seu interesse especificar o campo assunto de forma adequada.
+ Problema com o FreeBSD ou
+ Ajudem-me não são adequados.
+ Se você não especificar um assunto, muitas
+ pessoas não se incomodarão em ler a sua
+ mensagem. Se o assunto da sua mensagem não for
+ específico o suficiente, as pessoas que podem
+ responder a sua duvida podem não se interessar em ler
+ a sua mensagem.
+
+
+
+ Formate sua mensagem de forma que ela seja
+ legível, e POR FAVOR, NÃO GRITE!!!!!.
+ Nós sabemos que muitas pessoas não tem a
+ língua inglesa como seu idioma nativo, e tentamos
+ fazer concessões para estas pessoas, mas é
+ realmente doloroso tentar ler uma mensagem cheia de erros
+ tipográficos ou sem nenhuma quebra de linha.
+
+ Não subestime o efeito de uma mensagem de email
+ mal formatada, e não apenas na lista de
+ discussão FreeBSD-questions. A sua mensagem de email
+ é tudo que as outras pessoas vêem de
+ você, e se ela for mal formatada, possui apenas uma
+ linha por parágrafo, é mal escrita, ou
+ está cheia de erros, ela dará as outras
+ pessoas uma impressão negativa de você.
+
+ Muitas das mensagens mal formatadas vêm de clientes de email
+ ruins ou mal configurados. Os clientes de email a
+ seguir são conhecidos por enviar mensagens mal
+ formatadas:
+
+
+
+ cc:Mail
+
+
+
+ &eudora;
+
+
+
+ exmh
+
+
+
+ µsoft; Exchange
+
+
+
+ µsoft; Internet Mail
+
+
+
+ µsoft; &outlook;
+
+
+
+ &netscape;
+
+
+
+ Como você pode ver, os clientes de email do mundo
+ Microsoft são ofensores freqüentes. Sempre que
+ for possível utilize um cliente de email &unix;. Se
+ você precisar utilizar um cliente de email no ambiente
+ Microsoft, tenha certeza de que o configurou corretamente.
+ Tente não utilizar o MIME: muitas
+ pessoas usam clientes de email que não se entendem
+ bem com mensagens em formato MIME.
+
+
+
+ Certifique-se de que sua data e hora, assim como o seu
+ fuso horário estão corretamente configurados.
+ Isso pode parecer besteira, uma vez que sua mensagem ainda
+ estará lá, mas muitas pessoas que você
+ esta tentando alcançar começam o dia com
+ centenas de mensagens para ler. Eles freqüentemente
+ ordenam as mensagens que chegaram por assunto e por data e
+ se a sua mensagem não vier antes da primeira
+ resposta, eles podem assumir que a mensagem está
+ faltando e não se incomodarão em
+ procura-la.
+
+
+
+ Não inclua perguntas que não se relacionam
+ em uma mesma mensagem. Primeiro, uma mensagem longa tende a
+ espantar as pessoas, e segundo, é mais difícil
+ de conseguir que as pessoas que podem responder a todas as
+ suas perguntas leiam a mensagem.
+
+
+
+ Forneça o maior número de
+ informações relevantes quanto possível.
+ Esta é uma área difícil, e nós
+ precisamos detalhar quais informações
+ você deve enviar, mas aqui está um
+ começo:
+
+
+
+ Em praticamente todos os casos é importante
+ saber qual a versão do FreeBSD que você
+ está utilizando. Um caso particular é o
+ FreeBSD-Current, para o qual você deve fornecer
+ também a data do código, embora as
+ perguntas sobre o ramo -Current não devam ser
+ encaminhadas para a lista FreeBSD-questions.
+
+
+
+ No caso de qualquer problema que possa
+ estar relacionado a hardware, envie
+ informações sobre o seu hardware. No caso
+ de dúvida, assuma que seu problema pode ser
+ causado por um problema de hardware e nos envie suas
+ especificações. Que tipo de CPU
+ você está utilizando? Qual o clock do
+ processador? Qual a placa mãe? Qual a
+ quantidade de memória física instalada?
+ Quais outros periféricos você possui? Ao
+ responder perguntas como essa você terá uma
+ lista com as informações básicas a
+ enviar.
+
+ Há uma chamada de julgamento aqui,
+ naturalmente, a saída do comando &man.dmesg.8;
+ freqüentemente é muito útil, uma vez
+ que ele nos diz não apenas que componentes de
+ hardware que você esta utilizando, como
+ também qual a versão do FreeBSD.
+
+
+
+ Se você obtiver uma mensagem de erro,
+ não diga Eu recebi uma mensagem de
+ erro, diga (por exemplo) Eu recebi a
+ mensagem de erro 'No route to host'.
+
+
+
+ Se o seu sistema deu um panic, não diga
+ Meu sistema sofre um panic, diga (por
+ exemplo) Meu sistema sofreu um panic e a mensagem
+ de erro foi 'free vnode isn't'.
+
+
+
+ Se você esta com dificuldades na
+ instalação do FreeBSD, por favor nos diga
+ que hardware você possui. Em particular, é
+ importante conhecer os IRQs e os endereços de I/O
+ das placas que você tem instalado na sua
+ máquina.
+
+
+
+ Se você está com dificuldades para
+ colocar o PPP para rodar, descreva a sua
+ configuração. Qual versão do PPP
+ você está utilizando? Qual tipo de
+ autenticação você esta usando?
+ Você possui um IP dinâmico ou
+ estático? Quais tipos de mensagens você
+ tem no seu arquivo de log?
+
+
+
+
+
+ A maioria das informações que
+ você precisa fornecer são as saídas de
+ programas, tais como &man.dmesg.8;, ou mensagens de
+ console, as quais usualmente aparecem no
+ /var/log/messages. Não tente
+ copiar estas informações digitando-as
+ novamente; isto é realmente desnecessário, e
+ você estará cometendo um erro. Ao enviar o
+ conteúdo de um arquivo de log, faça uma
+ cópia do arquivo e utilize um editor de textos para
+ cortar as partes desnecessárias, deixando apenas as
+ que forem relevantes para a interpretação do
+ problema, ou simplesmente copie e cole o trecho relevante
+ para a sua mensagem. Para enviar a saída de
+ comandos, como o &man.dmesg.8;, redirecione a saída
+ do comando para um arquivo e inclua-o em sua mensagem.
+ Por exemplo,
+
+ &prompt.user; dmesg > /tmp/dmesg.out
+
+ Este comando redireciona as informações
+ para o arquivo /tmp/dmesg.out.
+
+
+
+ Se você fez tudo isso, e continua sem receber uma
+ resposta, podem existir outras razões. Por exemplo,
+ o problema pode ser muito complicado e ninguém
+ conhece a resposta, ou então a pessoa que conhece a
+ resposta está offline. Se você não
+ obtiver uma resposta depois de, digamos, uma semana, pode
+ ser útil reenviar a mensagem. Se você
+ não obtiver resposta para a sua segunda mensagem,
+ significa que você provavelmente não irá
+ obter uma nesta lista. Reenviar a mesma pergunta diversas
+ vezes para a mesma lista apenas irá torná-lo
+ impopular.
+
+
+
+ Para resumir, vamos assumir que você conhece a
+ resposta para as seguintes questões (sim, ambas
+ são sobre o mesmo assunto). Escolha qual destas duas
+ perguntas você estaria mais preparado para
+ responder:
+
+
+ Mensagem 1
+
+ Subject: HELP!!?!??
+Eu simplesmente não consigo colocar o raio do FreeBSD para funcionar,
+e eu sou geralmente bom nisso, mas eu nunca vi nada tão difícil de
+instalar, ele simplesmente não funciona, não importa o que eu faça.
+Por que vocês rapazes não me dizem o que eu estou fazendo errado?
+
+
+
+
+ Mensagem 2
+
+ Subject: Problemas para instalar o FreeBSD
+
+Eu comprei um CD do FreeBSD 2.1.5 na Walnut Creek, e eu estou tendo
+muita dificuldade para instala-lo. Eu possuo um 486 66Mhz com 16 Mb de
+memória, uma controladora SCSI Adaptec 1540A, um HD de 1.2GB Quantum
+Fireball e um drive cd cdrom Toshiba 3501XA. A instalação funciona
+perfeitamente, mas quando eu dou boot no sistema, eu recebo a
+mensagem Missing Operating System.
+
+
+
+
+ Como fazer um follow up em uma
+ pergunta
+
+
+ Frequentemente você pode desejar enviar alguma
+ informação adicional para uma pergunta que
+ você já enviou. A melhor forma de fazer isto
+ é dando um replay na sua mensagem original. Isto tem 3
+ vantagens>
+
+
+
+ Você inclui o texto original da mensagem, assim as
+ pessoas irão saber sobre oque você esta
+ falando. Não se esqueça de remover as partes
+ desnecessárias da mensagem original.
+
+
+
+ O texto na linha de assunto permanecerá o mesmo
+ (você se lembrou de colocar um, não lembrou?).
+ Muitos clientes de email irão ordenar as mensagens
+ pelo assunto. Isto ajuda a manter as mensagens de um mesmo
+ grupo juntas.
+
+
+
+ Os números de referência da mensagem no
+ cabeçalho irão apontar para a mensagem
+ anterior. Alguns clientes de email, como, por exemplo, o
+ mutt, podem
+ agrupar as mensagens por thread,
+ mostrando o relacionamento exato entre as mensagens.
+
+
+
+
+
+ Como responder uma pergunta
+
+
+ Antes que você responda uma pergunta para
+ FreeBSD-questions, considere:
+
+
+
+ Muitos dos pontos relacionados ao envio de uma pergunta,
+ também se aplicam quando respondemos à uma.
+ Leia os tópicos anteriores.
+
+
+
+ Alguém já respondeu a pergunta? A melhor
+ forma de verificar isso é ordenando as mensagens pelo
+ campo assunto: Então (esperamos) você
+ irá ver a pergunta seguida por qualquer resposta,
+ todas juntas.
+
+ Se alguém já tiver respondido a pergunta,
+ isso não significa automaticamente que você
+ não deve enviar outra. Mas tenha o bom senso de ler
+ todas as respostas já enviadas antes de enviar as
+ suas.
+
+
+
+ Você tem algo para contribuir alem daquilo que
+ já foi dito ? Em geral, respostas como Sim,
+ eu também não ajudam muito, mas
+ é claro existem exceções, como por
+ exemplo quando alguém está descrevendo um
+ problema que esta tendo, e que ele não sabe se foi
+ ocasionado por uma falha dele ou se alho está errado
+ com o hardware ou com o software que ele está usando.
+ Se você enviar uma resposta do tipo eu
+ também, você também deve incluir
+ qualquer outra informação relevante que
+ você tenha.
+
+
+
+ Você tem certeza de que entendeu a pergunta?
+ Muito freqüentemente, a pessoa que faz uma pergunta
+ esta confusa ou não se expressou muito bem. Mesmo
+ com a melhor compreensão do sistema, é
+ fácil enviar uma mensagem que não responda a
+ pergunta. Isto não ajuda: você irá
+ deixar a pessoa que enviou a pergunta mais frustrada ou
+ confusa do que antes. Se ninguém mais tiver
+ respondido, e você também não tiver
+ certeza, você sempre pode solicitar maiores
+ informações.
+
+
+
+ Você tem certeza de que a resposta está
+ correta? Se não, espere um dia ou mais. Se
+ ninguém mais aparecer com uma resposta melhor,
+ você pode enviar a sua resposta e dizer, por exemplo,
+ Eu não tenho certeza se estou correto, mas
+ como ninguém mais respondeu... Porque você
+ não tenta substituir o seu CDROM ATAPI por
+ outro?.
+
+
+
+ A menos que tenha uma boa razão para fazer
+ diferente, responda para a pessoa que enviou a pergunta e
+ para a FreeBSD-questions. Muitas pessoas inscritas na lista
+ são observadoras: Elas aprendem
+ através da leitura das mensagens enviadas e
+ respondidas pelas outras pessoas. Se você deixar uma
+ mensagem que é de interesse geral fora da lista,
+ você estará privando estas pessoas dessa
+ informação. Seja cuidadoso como as respostas
+ em grupo; muitas pessoas enviam mensagens com centenas de
+ endereços em CCs. Se este é o caso, tenha
+ certeza de ajustar as linhas Cc: de forma apropriada.
+
+
+
+ Inclua o texto relevante da mensagem original. Mantenha
+ o mínimo necessário do texto original, mas
+ não corte demais. Ele precisa ser conciso o
+ suficiente para que uma pessoa que não tenha lido a
+ mensagem original entender sobre o que você
+ está falando.
+
+
+
+ Utilize alguma técnica para identificar qual
+ parte da mensagem veio da mensagem original e qual parte foi
+ adicionada por você. Eu pessoalmente acho que
+ adicionar > no inicio
+ de cada linha da mensagem original é o que funciona
+ melhor. Procure deixar um espaço em branco depois do
+ > e sempre use uma
+ linha vazia entre a sua resposta e o texto original, isso
+ deixará sua mensagem mais legível.
+
+
+
+ Coloque sua resposta no local correto (Depois do texto
+ ao qual ela se aplica). É muito difícil ler
+ uma sequência de mensagens, onde as respostas vem
+ antes do texto ao qual elas se aplicam.
+
+
+
+ A maioria dos clientes de email altera a linha de
+ assunto em uma resposta adicionando um texto como Re:
+ ao inicio da linha. Se o seu cliente não
+ fizer isso de forma automática você deve
+ fazê-lo manualmente.
+
+
+
+ Se a pessoa que enviou a pergunta não respeitou
+ as convenções de formatação
+ (linhas muito longas, Linha de assunto inapropriada, etc),
+ por favor, corrija-a. No caso do uso
+ de uma linha de assunto inapropriada (como, por exemplo,
+ Ajudem-me!!??), altere a linha de assunto
+ para algo relacionado ao assunto da mensagem, mas mantenha
+ uma indicação de qual era o assunto original,
+ por exemplo,Re: Dificuldades com o PPP em modo
+ síncrono (era: Ajudem-me!!??). Desta forma
+ as outras pessoas que estão tentando acompanhar a
+ discussão irão ter menos dificuldades para
+ acompanhá-la.
+
+ Nesses casos, é apropriado dizer o que você
+ fez e porque você o fez, mas tente a não ser
+ rude. Se você acreditar que não pode responder
+ sem ser rude, simplesmente não responda.
+
+ Se você quiser responder uma mensagem por causa
+ de sua má formatação, responda-a
+ apenas para quem a enviou, e não para a lista.
+ Se você preferir, na resposta você pode apenas
+ recomendar que ele leia este artigo.
+
+
+
+
Modified: head/pt_BR.ISO8859-1/share/sgml/mailing-lists.ent
==============================================================================
--- head/pt_BR.ISO8859-1/share/sgml/mailing-lists.ent Wed Sep 5 05:42:34 2012 (r39504)
+++ head/pt_BR.ISO8859-1/share/sgml/mailing-lists.ent Wed Sep 5 05:47:06 2012 (r39505)
@@ -336,3 +336,11 @@
bug-followup@FreeBSD.org">
+
+FreeBSD CVS ports commit list">
+cvs-ports">
+
+
+FreeBSD ports bugs mailing list">
+freebsd-ports-bugs">
+
From owner-svn-doc-head@FreeBSD.ORG Wed Sep 5 05:52:11 2012
Return-Path:
Delivered-To: svn-doc-head@freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52])
by hub.freebsd.org (Postfix) with ESMTP id DB4781065670;
Wed, 5 Sep 2012 05:52:11 +0000 (UTC)
(envelope-from gabor@FreeBSD.org)
Received: from svn.freebsd.org (svn.freebsd.org [IPv6:2001:4f8:fff6::2c])
by mx1.freebsd.org (Postfix) with ESMTP id C43758FC12;
Wed, 5 Sep 2012 05:52:11 +0000 (UTC)
Received: from svn.freebsd.org (localhost [127.0.0.1])
by svn.freebsd.org (8.14.4/8.14.4) with ESMTP id q855qBDk083516;
Wed, 5 Sep 2012 05:52:11 GMT (envelope-from gabor@svn.freebsd.org)
Received: (from gabor@localhost)
by svn.freebsd.org (8.14.4/8.14.4/Submit) id q855qBYm083511;
Wed, 5 Sep 2012 05:52:11 GMT (envelope-from gabor@svn.freebsd.org)
Message-Id: <201209050552.q855qBYm083511@svn.freebsd.org>
From: Gabor Kovesdan
Date: Wed, 5 Sep 2012 05:52:11 +0000 (UTC)
To: doc-committers@freebsd.org, svn-doc-all@freebsd.org,
svn-doc-head@freebsd.org
X-SVN-Group: doc-head
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Cc:
Subject: svn commit: r39506 - in head/pt_BR.ISO8859-1: articles
articles/contributing-ports share/sgml
X-BeenThere: svn-doc-head@freebsd.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: SVN commit messages for the doc tree for head
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Wed, 05 Sep 2012 05:52:12 -0000
Author: gabor
Date: Wed Sep 5 05:52:11 2012
New Revision: 39506
URL: http://svn.freebsd.org/changeset/doc/39506
Log:
- Add new Brazilian Portuguese translation of the contributing-ports article
PR: docs/170831
Submitted by: Edson Brandi
Obtained from: The FreeBSD Brazilian Portuguese Documentation Project
(http://doc.fug.com.br)
Added:
head/pt_BR.ISO8859-1/articles/contributing-ports/
head/pt_BR.ISO8859-1/articles/contributing-ports/Makefile (contents, props changed)
head/pt_BR.ISO8859-1/articles/contributing-ports/article.sgml (contents, props changed)
Modified:
head/pt_BR.ISO8859-1/articles/Makefile
head/pt_BR.ISO8859-1/share/sgml/mailing-lists.ent
Modified: head/pt_BR.ISO8859-1/articles/Makefile
==============================================================================
--- head/pt_BR.ISO8859-1/articles/Makefile Wed Sep 5 05:47:06 2012 (r39505)
+++ head/pt_BR.ISO8859-1/articles/Makefile Wed Sep 5 05:52:11 2012 (r39506)
@@ -10,6 +10,7 @@
SUBDIR =
SUBDIR+= contributing
+SUBDIR+= contributing-ports
SUBDIR+= explaining-bsd
SUBDIR+= freebsd-questions
SUBDIR+= linux-users
Added: head/pt_BR.ISO8859-1/articles/contributing-ports/Makefile
==============================================================================
--- /dev/null 00:00:00 1970 (empty, because file is newly added)
+++ head/pt_BR.ISO8859-1/articles/contributing-ports/Makefile Wed Sep 5 05:52:11 2012 (r39506)
@@ -0,0 +1,24 @@
+#
+# The FreeBSD Documentation Project
+# The FreeBSD Brazilian Portuguese Documentation Project
+#
+# $FreeBSD$
+#
+# Original revision: r38826
+#
+# Article: Contributing to the FreeBSD Ports Collection
+
+DOC?= article
+
+FORMATS?= html html-split
+WITH_ARTICLE_TOC?= YES
+
+INSTALL_COMPRESSED?=gz
+INSTALL_ONLY_COMPRESSED?=
+
+SRCS= article.sgml
+
+URL_RELPREFIX?= ../../../..
+DOC_PREFIX?= ${.CURDIR}/../../..
+
+.include "${DOC_PREFIX}/share/mk/doc.project.mk"
Added: head/pt_BR.ISO8859-1/articles/contributing-ports/article.sgml
==============================================================================
--- /dev/null 00:00:00 1970 (empty, because file is newly added)
+++ head/pt_BR.ISO8859-1/articles/contributing-ports/article.sgml Wed Sep 5 05:52:11 2012 (r39506)
@@ -0,0 +1,1076 @@
+
+
+
+%articles.ent;
+
+]>
+
+
+ Contribuindo para a Coleção de Ports do
+ FreeBSD
+
+ $FreeBSD$
+
+
+ Sumário
+
+ Este artigo descreve as formas pelas quais uma pessoa pode
+ contribuir com a Coleção de
+ Ports do FreeBSD.
+
+
+
+
+ Sam
+ Lawrance
+
+
+ Mark
+ Linimon
+
+
+
+
+ &tm-attrib.freebsd;
+ &tm-attrib.general;
+
+
+
+ Contribuindo com o ports
+
+
+ Introdução
+
+ A Coleção de Ports
+ é um trabalho permanente, em constante
+ evolução. Nós queremos oferecer
+ aos nossos usuários um repositório de
+ softwares de terceiros que seja fácil de utilizar,
+ atualizado e de alta qualidade.
+
+ Qualquer um pode se envolver, e existem muitas formas
+ diferentes de fazer isso. Contribuir para a
+ coleção de ports é
+ uma excelente forma de ajudar e de devolver
+ algo para o projeto. Não importa se você
+ está à procura de participação
+ contínua, ou apenas um desafio divertido para um dia
+ chuvoso, nós vamos adorar receber a sua ajuda!
+
+
+ Como voluntário, o que você faz é limitado
+ apenas pelo que você quer fazer. No entanto, pedimos que
+ você tome conhecimento do que os outros membros da
+ comunidade &os; irão esperar de você. Você
+ pode querer levar isso em conta antes de decidir se
+ voluntariar.
+
+
+
+ O que você pode fazer para ajudar
+
+ Existem várias maneiras pelas quais você pode
+ contribuir para manter a árvore de
+ Ports atualizada e em boas
+ condições de funcionamento:
+
+
+
+ Encontre algum software legal e útil e
+ crie um
+ port para ele.
+
+
+
+ Existe um grande número de
+ ports que não têm nenhum
+ mantenedor (maintainer). Torne-se um
+ mantenedor e adote um
+ port.
+
+
+
+ Se você tiver criado ou adotado um
+ port, tome conhecimento do que precisa fazer agora que
+ é um mantenedor.
+
+
+
+ Quando você estiver procurando por um desafio
+ rápido você pode corrigir um bug ou um
+ port quebrado.
+
+
+
+
+
+ Criando um novo port
+
+ Existe um documento separado, disponível para ajudar
+ e guiá-lo no processo de criação (ou de
+ atualização) de um port,
+ chamado Porter's
+ Handbook. O Porter's
+ Handbook é a melhor fonte de referência
+ para se trabalhar no sistema de ports. Ele
+ fornece detalhes de como o sistema de ports
+ funciona e discute as boas práticas recomendadas.
+
+
+
+ Adotando um port sem
+ manutenção
+
+
+ Escolhendo um port sem
+ manutenção
+
+ Assumir a responsabilidade pela manutenção
+ de um port que está abandonado
+ é uma excelente forma de se envolver.
+ Ports sem manutenção
+ só são atualizados ou consertados quando
+ alguém se voluntaria à trabalhar neles.
+ Existe um grande número de ports
+ sem manutenção. É uma boa idéia
+ iniciar com a adoção de um
+ port que você usa
+ regularmente.
+
+ Os ports sem manutenção
+ tem a variável MAINTAINER setada
+ como ports@FreeBSD.org em seu
+ Makefile. A lista dos
+ ports sem manutenção, seus
+ erros atuais, e seus respectivos relatórios de problema
+ , pode ser vista no Sistema
+ de Monitoração de Ports do
+ FreeBSD.
+
+ Alguns ports afetam um grande
+ número de outros devido as suas dependências e
+ aos ports escravos. Você deve
+ esperar até que tenha alguma experiência antes
+ de se voluntariar para manter um port
+ destes.
+
+ Você pode descobrir se um port
+ tem ou não dependências ou
+ ports
+ escravos, observando o índice principal de ports
+ chamado INDEX. (O nome do arquivo varia
+ de acordo com a release do &os;; por exemplo,
+ INDEX-8.) Alguns
+ ports têm dependências
+ condicionais que não são incluídas na
+ compilação padrão do
+ INDEX. Esperamos que você seja
+ capaz de identificar estes ports
+ observando os Makefiles dos outros
+ ports.
+
+
+
+ Como adotar um port
+
+ Primeiro certifique-se de que você compreende as
+ suas responsabilidades como um
+ mantenedor. Também leia o Porter's Handbook.
+ Por favor, não se comprometa com mais do
+ que o que você se sente capaz de
+ fazer.
+
+ Você pode pedir para se tornar o responsável
+ por um port sem manutenção no
+ momento em que desejar. Basta definir o
+ MAINTAINER para o seu próprio email
+ e enviar um PR (relatório de problema) com a
+ mudança. Se o port tiver erros de
+ compilação ou se estiver precisando de
+ atualização, você pode querer enviar
+ quaisquer outras alterações no mesmo PR. Isto
+ irá ajudar porque muitos comitters
+ estão pouco dispostos a designar alguém sem um
+ histórico conhecido junto ao &os; como
+ responsável pela manutenção de um
+ port. Enviar PRs os quais corrigem erros
+ de compilação ou que atualizam
+ ports é a melhor forma de
+ estabelecer um.
+
+ Envie o seu PR com a categoria ports
+ e a classe change-request. Um
+ comitter irá examinar o seu PR, dar
+ commit das alterações e
+ finalmente fechar o seu PR. Algumas vezes este processo pode
+ demorar um pouco (afinal os comitters
+ também são voluntários).
+
+
+
+
+ Os desafios dos mantenedores de
+ ports
+
+ Esta seção lhe dará uma idéia de
+ porque os ports precisam ser mantidos e
+ irá apresentar as responsabilidades de um mantenedor de
+ ports.
+
+
+ Porque os ports precisam de
+ manutenção
+
+ Criar um port é uma tarefa que
+ demanda esforço uma única vez. Garantir que um
+ port está atualizado e que continua
+ a compilar e a executar é um esforço de
+ manutenção permanente. Os mantenedores
+ (maintainers), são pessoas as quais
+ dedicam uma parte do seu tempo para a realização
+ destes objetivos.
+
+ A principal razão pela qual o sistema de
+ ports precisa de manutenção
+ é trazer os melhores e mais recentes softwares de
+ terceiros para a comunidade &os;. Um desafio adicional
+ é manter os ports individuais
+ trabalhando com o framework da
+ Coleção de Ports a medida que
+ ele evolui.
+
+ Como mantenedor, você vai precisar gerenciar os
+ seguintes desafios:
+
+
+
+
+ Novas versões de software e
+ atualizações.
+
+ Novas versões e atualizações de
+ softwares que já pertencem ao
+ ports tornam-se disponíveis o
+ tempo todo, e estes têm de ser incorporados a
+ Coleção de Ports a fim
+ de atualizar os softwares disponibilizados por
+ ela.
+
+
+
+
+
+ Alterações em
+ dependências.
+
+ Se forem feitas mudanças significativas nas
+ dependências de seu port, ele
+ pode precisar ser atualizado para que continue a
+ funcionar corretamente.
+
+
+
+
+
+ Alterações que afetam
+ ports que dependem do seu.
+
+ Se outros ports dependem de um
+ port que você mantém,
+ alterações em seu port
+ podem demandar coordenação com outros
+ mantenedores.
+
+
+
+
+
+ Interação com outros usuários,
+ mantenedores e desenvolvedores.
+
+ Parte do trabalho de um mantenedor é atuar no
+ suporte. Não esperamos que você
+ ofereça suporte generalizado (mas será bem
+ vindo se você optar por isto). O que você
+ deve oferecer é um ponto de
+ coordenação para questões sobre
+ os seus ports que sejam especificos
+ ao &os;.
+
+
+
+
+
+ Caça aos bugs.
+
+ Um port pode ser afetado por
+ erros que são específicos ao &os;.
+ Você vai precisar investigar, encontrar e
+ corrigir estes erros quando eles forem reportados.
+ Testar exaustivamente um port para
+ identificar problemas antes que eles cheguem na
+ Coleção de Ports
+ é ainda melhor.
+
+
+
+
+
+ Alterações na política e na
+ infra-estrutura de ports.
+
+ Ocasionalmente, os sistemas que são
+ utilizados para compilar os ports
+ e os pacotes são atualizados ou uma nova
+ recomendação que afeta esta
+ infra-estrutura é feita. Você deve estar
+ ciente destas alterações para o caso dos
+ seus ports serem afetados e
+ precisarem de atualização.
+
+
+
+
+
+ Alterações no sistema base.
+
+ O &os; está em constante desenvolvimento.
+ Alterações ao software, as bibliotecas, ao
+ kernel ou mesmo alterações na
+ política podem alterar os requisitos de um
+ port.
+
+
+
+
+
+
+ Responsabilidades de um Mantenedor
+
+
+ Mantenha seus ports
+ atualizados
+
+ Esta seção descreve o processo que
+ você deve seguir para manter seus
+ ports atualizados.
+
+ Esta é uma visão geral. Maiores
+ informações sobre o processo de
+ atualização de um port
+ estão disponíveis no
+
+ Porter's Handbook.
+
+
+
+ Fique atentendo para as
+ atualizações
+
+ Monitore o desenvolvedor para tomar conhecimento
+ sobre a liberação de novas versões,
+ atualizações, e correções de
+ segurança para o software do seu
+ port. Listas de discussão
+ destinadas a avisos de lançamentos ou
+ páginas web de notícias são
+ úteis para fazer isso.
+ Algumas vezes os usuários
+ irão entrar em contato com você e perguntar
+ quando o seu port será
+ atualizado. Se você está ocupado com
+ outras coisas ou se por qualquer outra razão
+ não pode fazer a atualização
+ naquele momento, pergunte se eles irão
+ ajudá-lo enviando um PR com a
+ atualização.
+
+ Você também pode receber um email
+ automático do sistema de
+ verificação de ports do &os;
+ informando que uma nova versão do seu
+ port's distfile está
+ disponível. Maiores informações
+ sobre este sistema (incluindo a de como parar emails
+ futuros) serão fornecidas na mensagem.
+
+
+
+ Incorpore as alterações
+
+ Quando elas se tornarem disponíveis,
+ incorpore as mudanças ao seu
+ port. Você precisa ser capaz
+ de gerar um patch entre o seu
+ port original e o seu
+ port atualizado.
+
+
+
+ Revisão e teste
+
+ Examine cuidadosamente e teste as suas
+ alterações:
+
+
+
+ Compile, instale e teste o seu
+ port no maior número
+ possível de plataformas e arquiteturas.
+ É comum que um port
+ funcione em um branch ou
+ plataforma e falhe em outra.
+
+
+
+ Certifique-se de que as dependências do
+ seu port estão completas.
+ A melhor forma de fazer isto é instalar a sua
+ própria ports
+ tinderbox. Consulte a
+ seção sobre recursos para maiores
+ informações.
+
+
+
+ Verifique se a lista de empacotamento
+ está atualizada. Isto envolve a
+ adição de novos arquivos e
+ diretórios e a remoção de
+ entradas não utilizadas.
+
+
+
+ Verifique o seu port
+ utilizando o &man.portlint.1; como um guia.
+ Consulte a seção sobre recursos para
+ informações importantes sobre o uso do
+ portlint.
+
+
+
+ Avalie se as alterações no seu
+ port podem levar a quebra de
+ outros ports. Se este for o
+ caso, coordene as alterações com os
+ mantenedores destes ports. Isto
+ é especialmente importante se a sua
+ atualização alterar a versão de
+ uma biblioteca compartilhada; neste caso, no
+ mínimo, os ports que forem
+ dependentes do seu vão precisar atualizar seu
+ PORTREVISION de modo que eles
+ sejam automaticamente atualizados pelas ferramentas
+ de automação tais como o
+ portmaster ou o
+ &man.portupgrade.1;.
+
+
+
+
+
+ Envie as alterações
+
+ Envie sua atualização através
+ da submissão de um PR contendo uma
+ explicação sobre as mudanças e um
+ patch com as diferenças entre o port original e a
+ versão atualizada. Por favor, consulte o artigo
+ Escrevendo
+ Relatórios de Problema para o FreeBSD
+ para maiores informações sobre como
+ escrever um bom PR.
+
+
+ Por favor, não envie um arquivo
+ &man.shar.1; com o port inteiro.
+ Em vez disso, utilize &man.diff.1;
+ -ruN. Desta forma, os
+ committers podem ver com muito mais
+ facilidade e precisão quais são as
+ mudanças que estão sendo feitas. A
+ seção Atualizações
+ do Porter's Handbook tem maiores
+ informações.
+
+
+
+
+ Aguarde
+
+ Em algum momento um committer vai
+ cuidar do seu PR. Isto pode demorar alguns minutos, ou
+ pode levar semanas — desta forma, por favor, seja
+ paciente.
+
+
+
+ Dê feedbacks
+
+ Se um committer encontrar um
+ problema nas suas alterações, ele
+ provavelmente irá encaminhá-lo de volta
+ para você. Uma resposta rápida irá
+ ajudá-lo a ter o seu PR resolvido mais
+ rapidamente, e será melhor para manter o fluxo
+ de conversação quando se está
+ tentando resolver qualquer problema.
+
+
+
+ E finalmente...
+
+ As suas alterações serão
+ aceitas e o seu port estará
+ atualizado. O PR será fechado pelo
+ committer. E é isso!
+
+
+
+
+
+ Assegure que os seus ports continuem
+ compilando corretamente.
+
+ Esta seção é sobre descobrir e
+ corrigir problemas que impeçam os seus
+ ports de compilar corretamente.
+
+ O funcionamendo da Coleção de
+ Ports é garantido pelo &os; apenas no ramo
+ -STABLE do sistema. Você deve
+ estar executando o 8-STABLE ou o
+ 9-STABLE, preferencialmente o
+ último. Em teoria, você deve ser capaz de
+ usá-lo com a última release
+ de cada ramo estável (uma vez que as
+ ABIs não deveriam mudar) mas se
+ você puder executar o ramo -STABLE,
+ isto será ainda melhor.
+
+ Uma vez que a maioria das instalações do
+ FreeBSD rodam em maquinas PC compatíveis (como
+ é denominada a arquitetura i386),
+ nós esperamos que você mantenha os seus
+ ports funcionando nesta arquitetura.
+ Nós preferimos que os ports
+ também funcionem de forma nativa na arquitetura
+ amd64. É totalmente justo que
+ você peça ajuda se você não
+ possuir uma destas máquinas.
+
+
+ As falhas mais usuais na compilação para
+ máquinas não-i386 ocorrem
+ porque o programador original assumiu, por exemplo, que os
+ ponteiros são do tipo int, ou
+ então que uma versão antiga e relativamente
+ mais frouxa do compilador gcc
+ está sendo utilizada. Cada vez mais, os autores de
+ aplicações estão retrabalhando seu
+ código para remover estes pressupostos — mas
+ se o autor não estiver mantendo o código
+ de forma ativa, você pode precisar fazer isto
+ você mesmo.
+
+
+ Estas são as tarefas que precisam ser executadas
+ para garantir o seu port pode ser
+ compilado:
+
+
+
+ Esteja atento para falhas de
+ compilação
+
+ Verifique regularmente o cluster de
+ compilação automatizada de
+ ports, o pointyhat, e
+ o scanner de
+ arquivos de distribuição para ver
+ se algum dos ports que você
+ mantém está falhando na
+ compilação ou no download do
+ código fonte (veja a seção sobre
+ recursos para maiores
+ informações sobre estes sistemas).
+ Relatórios de falha também podem chegar
+ até você por email, vindos de outros
+ usuários ou dos sistemas automatizados.
+
+
+
+ Colete informações
+
+ Uma vez que você tome conhecimento de um
+ problema, colete informações para
+ ajudá-lo a corrigi-lo. Os erros de
+ compilação reportados pelo pointyhay
+ são acompanhados por
+ logs os quais irão lhe mostrar onde a
+ compilação falhou. Se a falha tiver sido
+ reportada à você por um usuário,
+ peça a ele para lhe enviar
+ informações as quais possam lhe ajudar no
+ diagnóstico do problema, tais como:
+
+
+
+ Logs de compilação
+
+
+
+ Os comandos e as opções que foram
+ utilizadas para compilar o port
+ (incluindo as opções definidas no
+ /etc/make.conf)
+
+
+
+ A lista de aplicativos instalados em seus
+ sistemas, como mostrada pelo &man.pkg.info.1;
+
+
+
+ A versão do &os; que eles estão
+ utilizando, como mostrada pelo
+ &man.uname.1; -a
+
+
+
+ Quando a sua Coleção de
+ Ports foi atualizada pela
+ última vez
+
+
+
+ Quando o seu arquivo INDEX
+ foi atualizado pela última vez
+
+
+
+
+
+ Investigue e encontre uma
+ solução
+
+ Infelizmente não existe um processo simples
+ a ser seguido para fazer isto. Porém
+ lembre-se: Se você estiver sem saber o que
+ fazer, peça ajuda! A &a.ports; é um bom
+ lugar para começar, e os desenvolvedores do
+ software também estão frequentemente
+ dispostos a ajudar.
+
+
+
+ Envie as alterações
+
+ Assim como na atualização de um
+ port, você agora deve
+ incorporar as alterações,
+ revisá-las, testá-las, e depois submeter
+ um PR com elas, fornecendo feedback, se
+ necessário.
+
+
+
+ Envie patches para os
+ desenvolvedores do software
+
+ Em alguns casos você irá precisar
+ modificar o software do seu port para
+ que ele execute no &os;. Alguns (mas não todos)
+ desenvolvedores irão aceitar incorporar tais
+ patches em seu código para a
+ próxima release. Se eles aceitarem, isto pode
+ até ajudar os seus usuários nos outros
+ sistemas derivados do BSD e talvez evite esforços
+ duplicados. Por favor, considere o envio de qualquer
+ patch aplicável aos
+ desenvolvedores do software como uma cortesia.
+
+
+
+
+
+
+ Investigue os relatórios de bugs e os PRs
+ relacionados ao seu port
+
+ Esta seção é sobre a descoberta
+ e correção de bugs.
+
+ Os bugs específicos ao &os; são geralmente
+ causados por suposições feitas pelo
+ desenvolvedor sobre o ambiente de compilação e
+ de execução que não se aplicam ao &os;.
+ É pouco provável que você encontre um
+ problema deste tipo, eles são mais sutis e
+ difíceis de diagnosticar.
+
+ Estas são as tarefas que precisam ser executadas
+ para garantir que o seu port continua
+ funcionando como esperado:
+
+
+
+ Responda os relatórios de bugs
+
+ Bugs podem ser reportados para você por
+ meio de email através do Banco
+ de Dados de Relatórios de Problema GNATS.
+ Bugs também podem ser reportados diretamente
+ à você pelos usuários.
+
+ Você deve responder os PRs e demais
+ relatórios no prazo de até 14 dias, mas
+ por favor tente não levar tanto tempo. Tente
+ responder o mais rápido possível, mesmo
+ que seja só para dizer que você precisa de
+ mais algum tempo antes que você possa trabalhar no
+ PR.
+
+ Se você não responder neste prazo de 14
+ dias, qualquer committer
+ poderá realizar o commit do PR
+ ao qual você não respondeu baseado na regra
+ de maintainer-timeout.
+
+
+
+ Colete informações
+
+ Se a pessoa que reportou o bug não tiver
+ fornecido também uma correção,
+ você vai precisar coletar as
+ informações que irão lhe
+ permitir gerar uma.
+
+ Se o bug pode ser reproduzido, você pode
+ coletar a maioria das informações
+ necessárias você mesmo. Se não
+ conseguir reproduzi-lo, peça para a pessoa que
+ reportou o bug para coletar as informações
+ para você, tais como:
+
+
+
+ Uma descrição detalhada das suas
+ ações, comportamento esperado para o
+ programa e o seu comportamento atual
+
+
+
+ Cópia dos dados que desencadearam o
+ bug
+
+
+
+ Informação sobre o seu ambiente de
+ compilação e execução
+ — como, por exemplo, a lista dos aplicativos
+ instalados e a saída do &man.env.1;
+
+
+
+ Dumps de memória
+
+
+
+ Rastreamento de pilhas
+
+
+
+
+
+ Elimine os relatórios incorretos
+
+ Alguns dos relatórios de bugs podem estar
+ incorretos. Por exemplo, o usuário pode ter
+ simplesmente utilizado o programa de forma errada; ou os
+ aplicativos instalados podem estar desatualizados e
+ precisando de atualização. À
+ vezes, o bug reportado não é
+ específico ao &os;. Neste caso, relate o bug
+ para o desenvolvedor do software. Se a
+ correção do bug estiver dentro da sua
+ capacidade técnica, você também pode
+ aplicar um patch ao seu
+ port, para que a
+ correção seja disponibilizada antes do
+ release da nova versão oficial por parte do
+ desenvolvedor.
+
+
+
+ Encontre uma solução
+
+ Assim como ocorre com os erros de
+ compilação, você vai precisar
+ encontrar uma correção para o problema.
+ Mais uma vez, lembre-se de pedir ajuda se você
+ estiver sem saber por onde começar!
+
+
+
+ Envie ou aprove as alterações
+
+ Assim como ocorre na atualização de um
+ port, agora você deve
+ incorporar as alterações,
+ revisá-las, testá-las, e enviar as suas
+ mudanças em um PR (ou enviar um followup se
+ já existir um PR para o problema). Se outro
+ usuário tiver submetido alterações
+ em um PR, você também pode enviar um
+ followup dizendo se aprova ou não estas
+ mudanças.
+
+
+
+
+
+ Forneça suporte
+
+ Faz parte da função de mantenedor prover
+ suporte — não para o software em geral —
+ mas para o port e para qualquer problema
+ ou peculiaridade que seja específica do &os;.
+ Usuários podem contatá-lo com perguntas,
+ sugestões, problemas e patches.
+ Na maior parte do tempo serão mensagens especificas
+ ao &os;.
+
+ Ocasionalmente você pode precisar usar as suas
+ habilidades diplomáticas para gentilmente direcionar
+ os usuários que buscam suporte geral aos recursos
+ apropriados. Menos frequentemente você irá
+ encontrar pessoas perguntando por que o
+ RPM não está atualizado ou
+ como eles podem fazer o software executar no Linux XYZ.
+ Aproveite a oportunidade para informar que o seu
+ port está atualizado (se ele
+ estiver, é claro) e sugira que eles testem o
+ &os;.
+
+ À vezes os usuários e desenvolvedores
+ irão decidir que você é um pessoa
+ ocupada, cujo tempo é valioso e irão fazer
+ parte do trabalho para você. Por exemplo, eles
+ podem:
+
+
+ Submeter um PR ou enviar um patch
+ para atualizar o seu port,
+
+
+
+ investigar e talvez disponibilizar uma
+ correção para um PT, ou
+
+
+
+ de outra forma, submeter mudanças para o seu
+ port.
+
+
+
+ Nestes casos a sua principal obrigação
+ é responder rapidamente. Mais uma vez, o tempo
+ limite de espera pela resposta de um mantenedor é de
+ 14 dias. Após este período as
+ alterações podem ser processadas sem a sua
+ aprovação. Eles se deram ao trabalho de fazer
+ isto por você, portanto, tente pelo menos responder
+ prontamente. Em seguida analise, aprove, modifique ou
+ discuta as alterações com eles o mais
+ rapidamente possível.
+
+ Se você puder fazê-los sentir que a
+ contribuição deles é apreciada (e ela
+ deveria ser), você terá melhores chances de
+ persuadi-los a fazer mais coisas para você no futuro
+ :-).
+
+
+
+
+
+ Localizando e corrigindo um port
+ quebrado.
+
+ Existem dois lugares muito bons nos quais você pode
+ encontrar ports que precisam de alguma
+ atenção.
+
+ Você pode utilizar a interface
+ web do banco de dados dos Relatórios de Problema
+ para pesquisar e visualizar os PRs não resolvidos. A
+ maioria dos PRs da categoria ports são
+ referentes a atualizações, mas com um pouco de
+ pesquisa e leitura das sinopses você deverá ser
+ capaz de encontrar algo interessante para trabalhar (a classe
+ sw-bug é um bom ponto de
+ partida).
+
+ O outro lugar é o Sistema de
+ Monitoração de Ports do
+ &os;. Em especial, procure por ports
+ sem manutenção e com erros de
+ compilação e por ports que
+ estejam marcados como BROKEN (quebrados).
+ É OK enviar alterações para um
+ port que está sendo mantido, mas
+ lembre-se de consultar primeiro o mantenedor para o caso dele
+ já estar trabalhando na solução do
+ problema.
+
+ Depois que você tiver encontrado um bug ou problema,
+ colete informações, investigue e conserte! Se
+ existir já um PR, envie um followup. Caso
+ contrário, crie um novo PR. Suas
+ alterações serão revisadas e se tudo
+ estiver OK, serão processadas e incorporadas.
+
+
+
+ Saber quando parar
+
+ A medida que seus interesses e compromissos mudarem,
*** DIFF OUTPUT TRUNCATED AT 1000 LINES ***
From owner-svn-doc-head@FreeBSD.ORG Wed Sep 5 05:56:20 2012
Return-Path:
Delivered-To: svn-doc-head@freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34])
by hub.freebsd.org (Postfix) with ESMTP id 216DE106564A;
Wed, 5 Sep 2012 05:56:20 +0000 (UTC)
(envelope-from gabor@FreeBSD.org)
Received: from svn.freebsd.org (svn.freebsd.org [IPv6:2001:4f8:fff6::2c])
by mx1.freebsd.org (Postfix) with ESMTP id 0A9EC8FC0A;
Wed, 5 Sep 2012 05:56:20 +0000 (UTC)
Received: from svn.freebsd.org (localhost [127.0.0.1])
by svn.freebsd.org (8.14.4/8.14.4) with ESMTP id q855uJhI084030;
Wed, 5 Sep 2012 05:56:19 GMT (envelope-from gabor@svn.freebsd.org)
Received: (from gabor@localhost)
by svn.freebsd.org (8.14.4/8.14.4/Submit) id q855uJJG084026;
Wed, 5 Sep 2012 05:56:19 GMT (envelope-from gabor@svn.freebsd.org)
Message-Id: <201209050556.q855uJJG084026@svn.freebsd.org>
From: Gabor Kovesdan
Date: Wed, 5 Sep 2012 05:56:19 +0000 (UTC)
To: doc-committers@freebsd.org, svn-doc-all@freebsd.org,
svn-doc-head@freebsd.org
X-SVN-Group: doc-head
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Cc:
Subject: svn commit: r39507 - in head/pt_BR.ISO8859-1/articles: . new-users
X-BeenThere: svn-doc-head@freebsd.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: SVN commit messages for the doc tree for head
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Wed, 05 Sep 2012 05:56:20 -0000
Author: gabor
Date: Wed Sep 5 05:56:19 2012
New Revision: 39507
URL: http://svn.freebsd.org/changeset/doc/39507
Log:
- Add new Brazilian Portuguese translation of the new-users article
PR: docs/170965
Submitted by: Edson Brandi
Obtained from: The FreeBSD Brazilian Portuguese Documentation Project
(http://doc.fug.com.br)
Added:
head/pt_BR.ISO8859-1/articles/new-users/
head/pt_BR.ISO8859-1/articles/new-users/Makefile (contents, props changed)
head/pt_BR.ISO8859-1/articles/new-users/article.sgml (contents, props changed)
Modified:
head/pt_BR.ISO8859-1/articles/Makefile
Modified: head/pt_BR.ISO8859-1/articles/Makefile
==============================================================================
--- head/pt_BR.ISO8859-1/articles/Makefile Wed Sep 5 05:52:11 2012 (r39506)
+++ head/pt_BR.ISO8859-1/articles/Makefile Wed Sep 5 05:56:19 2012 (r39507)
@@ -14,6 +14,7 @@ SUBDIR+= contributing-ports
SUBDIR+= explaining-bsd
SUBDIR+= freebsd-questions
SUBDIR+= linux-users
+SUBDIR+= new-users
SUBDIR+= problem-reports
DOC_PREFIX?= ${.CURDIR}/../..
Added: head/pt_BR.ISO8859-1/articles/new-users/Makefile
==============================================================================
--- /dev/null 00:00:00 1970 (empty, because file is newly added)
+++ head/pt_BR.ISO8859-1/articles/new-users/Makefile Wed Sep 5 05:56:19 2012 (r39507)
@@ -0,0 +1,24 @@
+#
+# The FreeBSD Documentation Project
+# The FreeBSD Brazilian Portuguese Documentation Project
+#
+# $FreeBSD$
+#
+# Original revision: r38826
+#
+# Article: For People New to Both FreeBSD and Unix
+
+DOC?= article
+
+FORMATS?= html html-split
+WITH_ARTICLE_TOC?= YES
+
+INSTALL_COMPRESSED?=gz
+INSTALL_ONLY_COMPRESSED?=
+
+SRCS= article.sgml
+
+URL_RELPREFIX?= ../../../..
+DOC_PREFIX?= ${.CURDIR}/../../..
+
+.include "${DOC_PREFIX}/share/mk/doc.project.mk"
Added: head/pt_BR.ISO8859-1/articles/new-users/article.sgml
==============================================================================
--- /dev/null 00:00:00 1970 (empty, because file is newly added)
+++ head/pt_BR.ISO8859-1/articles/new-users/article.sgml Wed Sep 5 05:56:19 2012 (r39507)
@@ -0,0 +1,1223 @@
+
+
+
+%articles.ent;
+]>
+
+
+
+ Para os novatos em FreeBSD e &unix;
+
+
+
+ Annelise
+
+ Anderson
+
+
+ andrsn@andrsn.stanford.edu
+
+
+
+
+ 15 de agosto de 1997
+
+
+ &tm-attrib.freebsd;
+ &tm-attrib.ibm;
+ &tm-attrib.microsoft;
+ &tm-attrib.netscape;
+ &tm-attrib.opengroup;
+ &tm-attrib.general;
+
+
+
+ Parabéns pela instalação do FreeBSD!
+ Esta introdução é para os novatos no
+ FreeBSD e no &unix;—, então
+ ela começa com o básico. Este artigo assume que
+ você está usando a versão 2.0.5, ou mais
+ atual, do &os; distribuído pela &os;.org, seu sistema,
+ por agora, tem um único usuário (você) e
+ você provavelmente está muito bem com o
+ DOS/&windows; ou &os2;.
+
+
+
+
+ Entrando e saindo do sistema
+
+ Entre no sistema (quando você vê
+ login:) como o usuário que você
+ criou durante a instalação ou como
+ root. (Sua instalação do
+ FreeBSD já terá uma conta
+ root; que pode ir para qualquer lugar e
+ fazer qualquer coisa, incluindo remover arquivos essenciais,
+ então seja muito cuidadoso!) Os símbolos
+ &prompt.user; e &prompt.root; nos exemplos a seguir representam
+ o prompt (o seu pode ser diferente), com o
+ &prompt.user; indicando o prompt de um
+ usuário comum e o &prompt.root; indicando o
+ prompt do root.
+
+ Para sair do sistema (e obter uma novo
+ prompt de login:)
+ escreva:
+
+
+ &prompt.root; exit
+
+
+ quantas vezes forem necessárias. Você precisa
+ pressionar enter após os comandos, e
+ lembre-se que &unix; é sensível a letras
+ maiúsculas e minúsculas —
+ exit não é o mesmo que
+ EXIT.
+
+ Para desligar a máquina escreva:
+
+
+ &prompt.root; /sbin/shutdown -h now
+
+
+ Ou para reinicializar, escreva:
+
+
+ &prompt.root; /sbin/shutdown -r now
+
+
+ ou
+
+
+ &prompt.root; /sbin/reboot
+
+
+ Você também pode reiniciar com
+ CtrlAltDelete.
+ Dê-lhe um pouco de tempo para trabalhar. Isso é o
+ equivalente ao /sbin/reboot nas
+ versões recentes do FreeBSD e é muito, muito
+ melhor do que pressionar o botão de
+ reset. Você não quer ter que
+ instalar tudo de novo, não é?
+
+
+
+ Adicionando um Usuário com Privilégios de
+ Root
+
+ Se você não criou nenhum usuário
+ durante a instalação do sistema e, portanto,
+ está logado como root, você
+ provavelmente precisa criar um usuário agora com:
+
+
+ &prompt.root; adduser
+
+
+ Na primeira vez que você usar o
+ adduser, ele pode pedir por valores
+ padrões para salvar. Você pode querer definir o
+ shell padrão como &man.csh.1; ao
+ invés do &man.sh.1;, se ele sugerir o
+ sh como padrão. Do contrário,
+ apenas pressione enter para aceitar os valores
+ padrões. Os valores padrões serão
+ salvos em /etc/adduser.conf, o qual
+ pode ser editado.
+
+ Suponha que você criou um usuário
+ jack, cujo nome completo seja
+ Jack Benimble. Dê a
+ jack uma senha se segurança (mesmo
+ crianças ao redor que possam por as mãos no
+ teclado) é um problema. Quando for questionado se
+ você deseja incluir jack em outros
+ grupos, escreva wheel:
+
+
+ Login group is ``jack''. Invite jack into other groups: wheel
+
+
+ Isso tornará possível entrar no sistema como
+ jack e usar o comando &man.su.1; para
+ tornar-se root. Então você
+ não será mais repreendido por logar como
+ root.
+
+ Você pode interromper o adduser
+ à qualquer momento apenas pressionando
+ CtrlC, e
+ no fim você poderá aprovar o novo usuário
+ ou simplesmente escrever n para não.
+ Você pode querer criar um segundo usuário para o
+ caso de algo sair errado na edição dos arquivos de
+ login do usuário
+ jack.
+
+ Uma vez que você tenha concluído, use
+ exit para voltar ao prompt
+ de login e entrar como o usuário
+ jack. Em geral, é uma boa
+ idéia fazer tudo quanto for possível como um
+ usuário comum, que não tem o poder — e o
+ risco — do root.
+
+ Se você já criou o usuário e quer que
+ ele tenha permissão de utilizar o su
+ para tornar-se root, você pode entrar
+ como root e editar o arquivo
+ /etc/group, adicionando
+ jack ao grupo presente na primeira
+ linha (o grupo wheel). Mas primeiro
+ você precisa praticar com &man.vi.1;, o editor de texto
+ instalado nas versões mais recentes do FreeBSD — ou
+ usar um editor de texto mais simples, como o &man.ee.1;.
+
+ Para remover um usuário, use o comando
+ rmuser.
+
+
+
+ Explorando
+
+ Ao entrar como um usuário comum, explore e tente
+ alguns comandos que irão acessar as fontes de ajuda e
+ informação do FreeBSD.
+
+ Aqui estão alguns comandos e o que eles fazem:
+
+
+
+ id
+
+
+ Diz quem você é!
+
+
+
+
+ pwd
+
+
+ Mostra onde você está — o
+ diretório corrente de trabalho
+
+
+
+
+ ls
+
+
+ Lista os arquivos no diretório corrente.
+
+
+
+
+ ls
+
+
+ Lista os arquivos no diretório corrente com um
+ * depois de arquivos
+ executáveis, um / depois de
+ diretórios, e um @ depois de
+ links simbólicos.
+
+
+
+
+ ls
+
+
+ Lista os arquivos com detalhes — tamanho, data,
+ e permissões.
+
+
+
+
+ ls
+
+
+ Lista os arquivos ocultos, que iniciam com
+ ponto, com os outros. Se você
+ está como root, os arquivos
+ ocultos, que iniciam com ponto, são
+ mostrados sem a necessidade da opção
+ .
+
+
+
+
+ cd
+
+
+ Muda o diretório corrente. cd
+ .. sobe um nível
+ com relação ao diretório atual; note
+ o espaço depois do cd.
+ cd /usr/local
+ entra no diretório especificado. cd
+ ~ entra no
+ diretório home do usuário
+ logado — e.g., /usr/home/jack.
+ Tente cd /cdrom,
+ e execute ls, para descobrir se seu
+ CDROM está montado e funcionando.
+
+
+
+
+ view
+ filename
+
+
+ Permite que você visualize um arquivo (chamado
+ filename) sem modificar
+ seu conteúdo. Tente view
+ /etc/fstab. Escreva
+ :q para sair.
+
+
+
+
+ cat
+ filename
+
+
+ Mostra o conteúdo de
+ filename na tela. Se ele
+ é muito longo e você só consegue ver o
+ final do arquivo, pressione ScrollLock e
+ use up-arrow para navegar até o
+ topo do arquivo; você pode usar
+ ScrollLock também com
+ páginas de manual. Pressione
+ ScrollLock novamente para interromper o
+ rolamento de conteúdo. Você pode querer
+ experimentar o cat em alguns arquivos
+ ocultos no seu diretório home
+ — cat
+ .cshrc, cat
+ .login, cat
+ .profile.
+
+
+
+
+ Você vai encontrar aliases em seu
+ .cshrc para alguns comandos
+ ls (estes são muito convenientes).
+ Você pode criar outros aliases
+ editando .cshrc. Você pode criar
+ aliases disponíveis para todos os
+ usuários colocando-os no arquivo de
+ configuração principal do csh
+ o qual afeta todo o sistema, o
+ /etc/csh.cshrc.
+
+
+
+ Obtendo Ajuda e Informação
+
+ Aqui estão algumas fontes de ajuda úteis.
+ Text representa um termo de sua
+ escolha, para o qual você precisa de
+ informação ou ajuda — usualmente um comando
+ ou arquivo.
+
+
+
+ apropos
+ text
+
+
+ Tudo que contiver o texto
+ text na whatis
+ database.
+
+
+
+
+ man
+ text
+
+
+ Exibe a página de manual do
+ text. A maior fonte de
+ documentação para sistemas &unix;.
+ man ls vai lhe
+ mostrar todos os detalhes de como usar o comando
+ ls. Pressione Enter
+ para navegar através do texto,
+ CtrlB
+ para voltar uma página,
+ CtrlF
+ para avançar uma página,
+ q ou
+ CtrlC
+ para sair.
+
+
+
+
+ which
+ text
+
+
+ Informa onde, no path do
+ usuário, o comando text
+ é encontrado.
+
+
+
+
+ locate
+ text
+
+
+ Informa todos os caminhos onde o termo
+ text é
+ encontrado.
+
+
+
+
+ whatis
+ text
+
+
+ Informa o que o comando
+ text faz e qual sua
+ página de manual. Executar whatis
+ * vai lhe informar sobre todos os
+ binários no diretório corrente.
+
+
+
+
+ whereis
+ text
+
+
+ Encontra o arquivo text,
+ informando seu caminho completo.
+
+
+
+
+ Você pode querer experimentar usar
+ whatis em alguns comandos comuns, como
+ cat, more,
+ grep, mv,
+ find, tar,
+ chmod, chown,
+ date, e script.
+ more permite que você leia uma
+ página de cada vez, do mesmo modo como no DOS, e.g.,
+ ls -l | more ou more
+ filename. O
+ * funciona como curinga — e.g.,
+ ls w* vai mostrar os arquivos que
+ começam com w.
+
+ Algum desses programas não está trabalhando
+ muito bem? Ambos, &man.locate.1; e &man.whatis.1;, dependem de
+ uma base de dados recompilada semanalmente. Se sua
+ máquina não vai permanecer ligada (e rodando o
+ &os;) durante o final de semana, convém executar
+ manualmente os comandos de manutenção
+ diários, semanais, e mensais de vez em quando.
+ Execute-os como root e,
+ por agora, dê a cada um deles um tempo para finalizar
+ antes de você iniciar o próximo.
+
+
+ &prompt.root; periodic daily
+output omitted
+&prompt.root; periodic weekly
+output omitted
+&prompt.root; periodic monthly
+output omitted
+
+
+ Se você cansar de esperar, pressione
+ AltF2
+ para acessar outro virtual console, e
+ entre no sistema novamente. Afinal, ele é um sistema
+ multiusuário e multitarefa. No entanto, é
+ provável que esses comandos exibam mensagens na sua tela
+ enquanto eles estão rodando; você pode executar
+ clear em seu prompt para
+ limpar a tela. Uma vez que eles tenham executado, você
+ pode querer olhar em /var/mail/root e
+ /var/log/messages.
+
+ Executar tais comandos é parte da
+ administração do sistema — e como o
+ único usuário do sistema &unix;, você
+ é seu próprio administrador de sistemas.
+ Praticamente tudo que você precisa fazer como
+ root será para
+ administração de sistemas. Tais responsabilidades
+ não são muito bem exploradas, mesmo nos grossos
+ livros sobre &unix;, que parecem dedicar um grande espaço
+ para opções de menus em gerenciadores de janelas.
+ Você pode querer obter um dos dois livros principais sobre
+ administração de sistemas, ou Evi Nemeth et.al.'s
+ UNIX System Administration Handbook
+ (Prentice-Hall, 1995, ISBN 0-13-15051-7) — a segunda
+ edição da capa vermelha; ou Æleen Frisch's
+ Essential System Administration (O'Reilly
+ & Associates, 2002, ISBN 0-596-00343-9). Eu uso
+ Nemeth.
+
+
+
+ Editando Texto
+
+ Para configurar seu sistema, você precisará
+ editar arquivos de texto. Muitos deles estarão no
+ diretório /etc; e você
+ precisará do su para tornar-se
+ root e poder modificá-los.
+ Você pode utilizar o ee, por ser
+ fácil de usar, mas à longo prazo vale a pena
+ aprender o editor de texto vi. Um excelente
+ tutorial sobre o vi pode ser encontrado em
+ /usr/src/contrib/nvi/docs/tutorial, se
+ você tiver os fontes do sistema instalado.
+
+ Antes de editar um arquivo, você provavelmente
+ deveria fazer um backup dele. Suponha que você queira
+ editar o /etc/rc.conf. Você pode
+ simplesmente usar cd /etc para ir até
+ o diretório /etc e fazer:
+
+
+ &prompt.root; cp rc.conf rc.conf.orig
+
+
+ Isso vai copiar o rc.conf para
+ rc.conf.orig, e depois você
+ poderá copiar o rc.conf.orig para
+ rc.conf para recuperar o original. Mas o
+ melhor mesmo seria mover (renomear) e copiar novamente:
+
+
+ &prompt.root; mv rc.conf rc.conf.orig
+&prompt.root; cp rc.conf.orig rc.conf
+
+
+ pelo fato do comando mv preservar a data
+ e o dono originais do arquivo. Você pode agora editar o
+ rc.conf. Se você quiser o original
+ de volta, você faria mv rc.conf
+ rc.conf.myedit (assumindo que você queira
+ preservar a versão modificada) e então:
+
+
+ &prompt.root; mv rc.conf.orig rc.conf
+
+
+ para voltar as coisas do jeito que estavam.
+
+ Para editar um arquivo, faça:
+
+
+ &prompt.root; vi filename
+
+
+ Mova-se através do texto com as setas do teclado.
+ Esc (a tecla de escape) coloca o
+ vi em modo de comando. Aqui estão
+ alguns comandos:
+
+
+
+ x
+
+
+ Remove o caractere onde está o cursor
+
+
+
+
+ dd
+
+
+ remove a linha inteira (mesmo que ela quebre na
+ tela)
+
+
+
+
+ i
+
+
+ para inserir texto a partir do cursor
+
+
+
+
+ a
+
+
+ para inserir texto após o cursor
+
+
+
+
+ Uma vez que você digite i ou
+ a, você pode inserir o texto.
+ Esc coloca você de volta no modo de
+ comando
+
+
+
+ :w
+
+
+ para salvar suas modificações no disco
+ e continuar editando
+
+
+
+
+ :wq
+
+
+ para salvar as modificações e
+ sair
+
+
+
+
+ :q!
+
+
+ para sair sem salvar as
+ modificações
+
+
+
+
+ /text
+
+
+ para mover o curso para
+ text;
+ /Enter (a tecla enter)
+ para encontrar a próxima ocorrência de
+ text.
+
+
+
+
+ G
+
+
+ vai para o final do arquivo
+
+
+
+
+ nG
+
+
+ vai para a linha n no
+ arquivo, onde n é o
+ número.
+
+
+
+
+ CtrlL
+
+
+ para redesenhar a tela
+
+
+
+
+ Ctrlb e
+ Ctrlf
+
+
+ volta e avança na tela, respectivamente, assim
+ como fazem no more e
+ view.
+
+
+
+
+ Pratique com o vi em seu diretório
+ home, criando um novo arquivo com vi
+ filename, adicionando e
+ removendo texto, salvando o arquivo, e chamando-o de novo.
+ vi oferece muitas surpresas, pois ele
+ é realmente bastante complexo, e algumas vezes você
+ vai inadvertidamente executar um comando que vai fazer alguma
+ coisa que você não espera. (Algumas pessoas
+ realmente gostam do vi — ele é
+ mais poderoso que o DOS EDIT — procure sobre o comando
+ :r.) Use Esc uma ou mais
+ vezes para estar seguro de que você está no modo de
+ comando e continuar a partir daí se você tiver
+ problemas, salve frequentemente com :w, e use
+ :q! para sair e começar novamente (a
+ partir do seu último :w) quando
+ você precisar.
+
+ Agora você pode entrar no diretório
+ /etc com o cd, usar o
+ su para tornar-se root,
+ usar o vi para editar o arquivo
+ /etc/group, e adicionar um usuário
+ no grupo wheel para que ele tenha
+ privilégios de root. Só
+ adicione uma vírgula e o login do
+ usuário no fim da primeira linha do arquivo, pressione
+ Esc, e use :wq para escrever
+ suas alterações no disco e sair. Efeito
+ instantâneo. (Você não colocou um
+ espaço depois da vírgula, colocou?)
+
+
+
+ Imprimindo Arquivos no DOS
+
+ Neste ponto você provavelmente não tem uma
+ impressora funcionando, então aqui vai uma maneira de
+ criar um arquivo a partir de uma página de manual,
+ movê-lo para um disquete, e então imprimi-lo do
+ DOS. Suponhamos que você queira ler cuidadosamente sobre
+ mudança de permissões em arquivos (muito
+ importante). Você pode usar man chmod
+ para ler a respeito. O comando
+
+
+ &prompt.user; man chmod | col -b > chmod.txt
+
+
+ irá remover códigos de
+ formatação e enviar a página de manual para
+ o arquivo chmod.txt em vez de
+ mostrá-lo na tela. Agora coloque um disquete formatado
+ no DOS em seu drive de disquete a, use
+ o su para tornar-se
+ root, e escreva
+
+
+ &prompt.root; /sbin/mount -t msdosfs /dev/fd0 /mnt
+
+
+ para montar o drive de disquete em
+ /mnt.
+
+ Agora (você não precisa mais estar como
+ root, e você pode executar
+ exit para voltar para o usuário
+ inicial jack) você pode ir até
+ o diretório onde você criou o
+ chmod.txt e copiar o arquivo para o
+ disquete com:
+
+
+ &prompt.user; cp chmod.txt /mnt
+
+
+ e usar ls /mnt para obter a listagem do
+ diretório /mnt, que deveria mostrar
+ o arquivo chmod.txt.
+
+ Você pode querer criar um arquivo a partir do
+ /sbin/dmesg executando:
+
+
+ &prompt.user; /sbin/dmesg > dmesg.txt
+
+
+ e copiar o dmesg.txt para o disquete.
+ /sbin/dmesg é o registro das
+ mensagens de boot, e ele é útil
+ para entender o que o FreeBSD encontra durante a
+ inicialização. Se você enviar perguntas
+ para a &a.questions; ou para o grupo da USENET — como
+ O FreeBSD não encontra a minha unidade de fita, o
+ que eu faço? — as pessoas vão querer
+ saber o que o dmesg diz.
+
+ Você pode desmontar o drive de disquete agora (como
+ root) para retirá-lo com:
+
+
+ &prompt.root; /sbin/umount /mnt
+
+
+ e reiniciar para ir para o DOS. Copie os arquivos para um
+ diretório do DOS, chame-os com o DOS EDIT, &windows;
+ Notepad ou Wordpad, ou algum outro processador de texto,
+ faça uma pequena alteração para o arquivo
+ ser salvo, e imprima como você normalmente faz a partir do
+ DOS ou Windows. Espero que funcione! Páginas de manual
+ saem melhor se impressas com o comando print
+ do DOS. (Copiar arquivos do FreeBSD para uma
+ partição DOS montada ainda é, em alguns
+ casos, um pouco arriscado.)
+
+ Obter uma impressora imprimindo do FreeBSD envolve criar uma
+ entrada apropriada em /etc/printcap e criar
+ um diretório de spool correspondente
+ em /var/spool/output. Se sua impressora
+ está na lpt0 (nos DOS é
+ chamada de LPT1), você só
+ precisa ir para /var/spool/output e (como
+ root) criar o diretório
+ lpd executando: mkdir
+ lpd, se ele ainda não existe. Em seguida, a
+ impressora deve responder se ela estiver ligada durante a
+ inicialização, e lp ou
+ lpr deve enviar um arquivo para a impressora.
+ Se o arquivo vai ser impresso ou não, depende da
+ configuração, esta é coberta no FreeBSD
+ handbook.
+
+
+
+ Outros comando úteis
+
+
+
+ df
+
+
+ mostra os dispositivos montados e o espaço em
+ disco.
+
+
+
+
+ ps aux
+
+
+ mostra os processos rodando. ps ax
+ exibe uma lista compacta.
+
+
+
+
+ rm filename
+
+
+ exclui o arquivo
+ filename.
+
+
+
+
+ rm -R dir
+
+
+ remove o diretório
+ dir e todos os seus
+ subdiretórios — seja cuidadoso!
+
+
+
+
+ ls -R
+
+
+ lista os arquivos no diretório corrente e
+ todos os subdiretórios; eu usei uma variante,
+ ls -AFR > where.txt, para obter uma
+ lista de todos os arquivos de / e
+ (separadamente) /usr, antes de
+ descobrir um jeito melhor de encontrar arquivos.
+
+
+
+
+ passwd
+
+
+ para mudar a senha do usuário (ou a senha do
+ root)
+
+
+
+
+ man hier
+
+
+ exibe a página de manual sobre o sistema de
+ arquivos do &unix;
+
+
+
+
+ Use find para localizar
+ filename em /usr, ou
+ qualquer de seus subdiretórios, com
+
+
+ &prompt.user; find /usr -name "filename"
+
+
+ Você pode usar * como curinga em
+ "filename"
+ (que deve estar entre aspas). Se você diz para
+ find procurar em /, em
+ vez de /usr, ele vai procurar o arquivo em
+ todos os dispositivos montados, incluindo CDROM e as
+ partições DOS.
+
+ Um excelente livro que explica os comandos e
+ utilitários &unix; é Abrahams & Larson,
+ Unix for the Impatient (2nd ed.,
+ Addison-Wesley, 1996). Existe também uma grande
+ quantidade de informações sobre &unix; na
+ Internet.
+
+
+
+ Próximos Passos
+
+ Agora você deve ter as ferramentas que você
+ precisa para explorar e editar arquivos, então você
+ pode ter tudo ligado e funcionando. Existe uma grande
+ quantidade de informações no FreeBSD handbook (que
+ provavelmente está em seu disco rígido) e no
+ web site do FreeBSD.
+ Uma grande variedade de pacotes e ports
+ estáo disponível no CDROM, bem como no site web.
+ O handbook diz mais sobre como usá-los (obter um pacote,
+ se ele existir, com pkg_add
+ /cdrom/packages/All/nomepacote,
+ onde nomepacote é o nome do
+ pacote). O CDROM tem uma lista dos pacotes e
+ ports com uma breve descrição
+ em cdrom/packages/index,
+ cdrom/packages/index.txt, e
+ cdrom/ports/index, com as
+ descrições completas em
+ /cdrom/ports/*/*/pkg/DESCR, onde os
+ * representam subdiretórios das
+ categorias e dos nomes dos programas, respectivamente.
+
+ Se você achar o handbook muito sofisticado (com
+ lndir e tudo) sobre a
+ instalação de ports a partir do
+ CDROM, aqui está o que normalmente funciona:
+
+ Encontre o port que você quer,
+ digamos que seja o kermit. Haverá um
+ diretório para ele no CDROM. Copie o subdiretório
+ para /usr/local (um bom lugar para
+ adicionar programas que estarão disponíveis para
+ todos os usuários) com:
+
+
+ &prompt.root; cp -R /cdrom/ports/comm/kermit /usr/local
+
+
+ Isso deve resultar em um subdiretório
+ /usr/local/kermit onde estarão
+ todos os arquivos do subdiretório
+ kermit do CDROM.
+
+ Em seguida, crie o diretório
+ /usr/ports/distfiles, se ele ainda
+ não existe, usando mkdir. Agora
+ verifique em /cdrom/ports/distfiles por um
+ arquivo com o nome que indique o port que
+ você quer. Copie o arquivo para
+ /usr/ports/distfiles; nas versões
+ recentes você pode pular este passo, o FreeBSD vai fazer
+ isso por você. No caso do kermit
+ não existe distfile.
+
+ Vá até o subdiretório
+ /usr/local/kermit, onde estará o
+ arquivo Makefile. E execute
+
+
+ &prompt.root; make all install
+
+
+ Durante este processo o port vai obter
*** DIFF OUTPUT TRUNCATED AT 1000 LINES ***
From owner-svn-doc-head@FreeBSD.ORG Wed Sep 5 09:18:31 2012
Return-Path:
Delivered-To: svn-doc-head@freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34])
by hub.freebsd.org (Postfix) with ESMTP id 041291065673;
Wed, 5 Sep 2012 09:18:31 +0000 (UTC)
(envelope-from ryusuke@FreeBSD.org)
Received: from svn.freebsd.org (svn.freebsd.org [IPv6:2001:4f8:fff6::2c])
by mx1.freebsd.org (Postfix) with ESMTP id E26AE8FC0C;
Wed, 5 Sep 2012 09:18:30 +0000 (UTC)
Received: from svn.freebsd.org (localhost [127.0.0.1])
by svn.freebsd.org (8.14.4/8.14.4) with ESMTP id q859IUK3009119;
Wed, 5 Sep 2012 09:18:30 GMT (envelope-from ryusuke@svn.freebsd.org)
Received: (from ryusuke@localhost)
by svn.freebsd.org (8.14.4/8.14.4/Submit) id q859IUdw009116;
Wed, 5 Sep 2012 09:18:30 GMT (envelope-from ryusuke@svn.freebsd.org)
Message-Id: <201209050918.q859IUdw009116@svn.freebsd.org>
From: Ryusuke SUZUKI
Date: Wed, 5 Sep 2012 09:18:30 +0000 (UTC)
To: doc-committers@freebsd.org, svn-doc-all@freebsd.org,
svn-doc-head@freebsd.org
X-SVN-Group: doc-head
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Cc:
Subject: svn commit: r39508 - in head/ja_JP.eucJP/htdocs: search snapshots
X-BeenThere: svn-doc-head@freebsd.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: SVN commit messages for the doc tree for head
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Wed, 05 Sep 2012 09:18:31 -0000
Author: ryusuke
Date: Wed Sep 5 09:18:30 2012
New Revision: 39508
URL: http://svn.freebsd.org/changeset/doc/39508
Log:
- Merge the following from the English version:
r30513 -> r39498 head/ja_JP.eucJP/htdocs/search/site.map
r35658 -> r39465 head/ja_JP.eucJP/htdocs/snapshots/index.sgml
Modified:
head/ja_JP.eucJP/htdocs/search/site.map
head/ja_JP.eucJP/htdocs/snapshots/index.sgml
Modified: head/ja_JP.eucJP/htdocs/search/site.map
==============================================================================
--- head/ja_JP.eucJP/htdocs/search/site.map Wed Sep 5 05:56:19 2012 (r39507)
+++ head/ja_JP.eucJP/htdocs/search/site.map Wed Sep 5 09:18:30 2012 (r39508)
@@ -16,7 +16,7 @@
# easy to maintain.
#
# The FreeBSD Japanese Documentation Project
-# Original revision: 1.31
+# Original revision: r39498
#
# Main section
@@ -109,7 +109,6 @@ http://www.freebsdfoundation.org/|FreeBS
&enbase;/projects/busdma/index.html|Busdma ¤ª¤è¤Ó SMPng ¥É¥é¥¤¥Ð¤Î½ñ¤´¹¤¨
&enbase;/projects/c99/index.html|C99 & POSIX® Ŭ¹ç¥×¥í¥¸¥§¥¯¥È
&base;/projects/cvsweb.html|CVSweb
-&enbase;/projects/gnats4/index.html|FreeBSD GNATS Upgrade
&enbase;/projects/ideas/index.html|FreeBSD ¥×¥í¥¸¥§¥¯¥È¥¢¥¤¥Ç¥£¥¢
&base;/projects/mips/index.html|FreeBSD/MIPS
&enbase;/projects/netperf/index.html|Network Performance (netperf)
Modified: head/ja_JP.eucJP/htdocs/snapshots/index.sgml
==============================================================================
--- head/ja_JP.eucJP/htdocs/snapshots/index.sgml Wed Sep 5 05:56:19 2012 (r39507)
+++ head/ja_JP.eucJP/htdocs/snapshots/index.sgml Wed Sep 5 09:18:30 2012 (r39508)
@@ -9,11 +9,12 @@
]>
-
+
&header;
+