Page MenuHomeFreeBSD
Files F161378235

D57999.diff
No OneTemporary
Actions

D57999.diff
View Options

diff --git a/documentation/content/de/books/developers-handbook/secure/_index.adoc b/documentation/content/de/books/developers-handbook/secure/_index.adoc
--- a/documentation/content/de/books/developers-handbook/secure/_index.adoc
+++ b/documentation/content/de/books/developers-handbook/secure/_index.adoc
@@ -1,6 +1,6 @@
---
title: Kapitel 3. Sicheres Programmieren
-authors:
+authors:
- author: Murray Stokely
prev: books/developers-handbook/tools
next: books/developers-handbook/l10n
@@ -139,13 +139,13 @@
Betrachten wir nun, wie das Speicherabbild dieses Prozesses aussehen würde, wenn wir 160 Leerzeichen in unser kleines Programm eingeben, bevor wir Enter drücken.
-[XXX figure here!]
+[ XXX figure here! ]
Offensichtlich kann man durch böswilligere Eingaben bereits kompilierten Programmtext ausführen (wie z.B. exec(/bin/sh)).
=== Puffer-Überläufe vermeiden
-Die direkteste Lösung, um Stack-Überläufe zu vermeiden, ist immer grössenbegrenzten Speicher und String-Copy-Funktionen zu verwenden. `strncpy` und `strncat` sind Teil der C-Standardbibliothek. Diese Funktionen akzeptieren einen Längen-Parameter. Dieser Wert sollte nicht größer sein als die Länge des Zielpuffers. Die Funktionen kopieren dann bis zu `length` Bytes von der Quelle zum Ziel. Allerdings gibt es einige Probleme. Keine der Funktionen garantiert, dass die Zeichenkette NUL-terminiert ist, wenn die Größe des Eingabepuffers so groß ist wie das Ziel. Außerdem wird der Parameter length zwischen strncpy und strncat inkonsistent definiert, weshalb Programmierer leicht bezüglich der korrekten Verwendung durcheinander kommen können. Weiterhin gibt es einen spürbaren Leistungsverlust im Vergleich zu `strcpy`, wenn eine kurze Zeichenkette in einen großen Puffer kopiert wird. Denn `strncpy` fült den Puffer bis zur angegebenen Länge mit NUL auf.
+Die direkteste Lösung, um Stack-Überläufe zu vermeiden, ist immer grössenbegrenzten Speicher und String-Copy-Funktionen zu verwenden. `strncpy` und `strncat` sind Teil der C-Standardbibliothek. Diese Funktionen akzeptieren einen Längen-Parameter. Dieser Wert sollte nicht größer sein als die Länge des Zielpuffers. Die Funktionen kopieren dann bis zu `length` Bytes von der Quelle zum Ziel. Allerdings gibt es einige Probleme. Keine der Funktionen garantiert, dass die Zeichenkette NUL-terminiert ist, wenn die Größe des Eingabepuffers so groß ist wie das Ziel. Außerdem wird der Parameter length zwischen strncpy und strncat inkonsistent definiert, weshalb Programmierer leicht bezüglich der korrekten Verwendung durcheinander kommen können. Weiterhin gibt es einen spürbaren Leistungsverlust im Vergleich zu `strcpy`, wenn eine kurze Zeichenkette in einen großen Puffer kopiert wird. Denn `strncpy` fült den Puffer bis zur angegebenen Länge mit NUL auf.
In OpenBSD wurde eine weitere Möglichkeit zum kopieren von Speicherbereichen implementiert, die dieses Problem umgeht. Die Funktionen `strlcpy` und `strlcat` garantieren, dass das Ziel immer NUL-terminiert wird, wenn das Argument length ungleich null ist. Für weitere Informationen über diese Funktionen lesen Sie bitte crossref:bibliography[OpenBSD,6]. Die OpenBSD-Funktionen `strlcpy` und `strlcat` sind seit Version 3.3 auch in FreeBSD verfügbar.
diff --git a/documentation/content/de/books/handbook/advanced-networking/_index.adoc b/documentation/content/de/books/handbook/advanced-networking/_index.adoc
--- a/documentation/content/de/books/handbook/advanced-networking/_index.adoc
+++ b/documentation/content/de/books/handbook/advanced-networking/_index.adoc
@@ -306,7 +306,7 @@
% ifconfig | grep -B3 -i wireless
....
-+
++
In FreeBSD 11 und neueren Versionen verwenden Sie stattdessen diesen Befehl:
+
@@ -315,9 +315,9 @@
% sysctl net.wlan.devices
....
-+
++
Wenn der drahtlose Adapter nicht aufgeführt wird, könnte ein zusätzliches Kernelmodul erforderlich sein. Es besteht jedoch auch die Möglichkeit, dass der Adapter von FreeBSD nicht unterstützt wird.
-+
++
Dieses Beispiel verwendet einen drahtlosen Atheros-Adapter `ath0`.
. Fügen Sie in [.filename]#/etc/wpa_supplicant.conf# einen Eintrag für das Netzwerk hinzu. Wenn die Datei nicht existiert, müssen Sie diese erstellen. Ersetzen Sie _myssid_ und _psk_ durch die SSID und den PSK. Diese Informationen werden vom Netzwerkadministrator zur Verfügung gestellt.
+
@@ -890,7 +890,7 @@
<.> Das Feld `ca_cert` gibt den Pfad zum CA-Zertifikat an. Diese Datei wird zur Verifizierung des Server-Zertifikats benötigt.
-<.> Dieses Feld enthält die Parameter für die erste Phase der Authentifizierung, den TLS-Tunnel. Je nachdem, welcher Authentifizierungsserver benutzt wird, kann
+<.> Dieses Feld enthält die Parameter für die erste Phase der Authentifizierung, den TLS-Tunnel. Je nachdem, welcher Authentifizierungsserver benutzt wird, kann
ein spezifisches Label für die Authentifizierung verwendet werden. Meistens lautet das Label "client EAP encryption", dass durch `peaplabel=0` gesetzt wird. Weitere Informationen finden Sie in man:wpa_supplicant.conf[5].
<.> Das innerhalb des verschlüsselten TLS-Tunnels verwendete Authentifizierungsprotokoll. In unserem Beispiel handelt es sich dabei um `auth=MSCHAPV2`.
@@ -1256,7 +1256,7 @@
* Wird der Access Point bei der Suche nicht gefunden, überprüfen Sie, dass die Konfiguration des drahtlosen Geräts nicht die Anzahl der Kanäle beschränkt.
* Wenn sich das Gerät nicht mit dem Access Point verbinden kann, überprüfen Sie, ob die Konfiguration der Station auch der des Access Points entspricht. Dazu gehören auch die Authentifzierungsmethode und die Sicherheitsprotokolle. Halten Sie die Konfiguration so einfach wie möglich. Wenn Sie ein Sicherheitsprotokoll wie WPA oder WEP verwenden, können Sie testweise den Access Point auf _offene Authentifizierung_ und _keine Sicherheit_ einstellen.
-+
++
Für die Fehlersuche steht man:wpa_supplicant[8] zur Verfügung. Starten Sie das Programm manuell mit der Option `-dd` und durchsuchen Sie anschließend die Systemprotokolle nach eventuellen Fehlermeldungen.
* Sobald sich das Gerät mit dem Access Point verbinden kann, prüfen Sie die Netzwerkkonfiguration mit einfachen Werkzeugen wie man:ping[8].
* Zusätzlich gibt es auch zahlreiche Low-Level-Debugging-Werkzeuge. Die Ausgabe von Debugging-Informationen des 802.11 Protocol Support Layers lassen sich mit dem Programm man:wlandebug[8] aktivieren. Um beispielsweise während der Suche nach Access Points und des Aufbaus von 802.11-Verbindungen (Handshake) auftretende Systemmeldungen auf die Konsole auszugeben, verwenden Sie den folgenden Befehl:
@@ -1266,7 +1266,7 @@
# wlandebug -i wlan0 +scan+auth+debug+assoc
net.wlan.0.debug: 0 => 0xc80000<assoc,auth,scan>
....
-+
++
Der 802.11-Layer liefert umfangreiche Statistiken, die mit dem Werkzeug `wlanstats`, das sich in [.filename]#/usr/src/tools/tools/net80211# befindet, abgerufen werden können. Diese Statistiken sollten alle Fehler identifizieren, die im 802.11-Layer auftreten. Beachten Sie aber, dass einige Fehler bereits im darunterliegenden Gerätetreiber auftreten und daher in diesen Statistiken nicht enthalten sind. Wie Sie Probleme des Gerätetreibers identifizieren, entnehmen Sie bitte der Dokumentation des Gerätetreibers.
Wenn die oben genannten Informationen nicht helfen das Problem zu klären, erstellen Sie einen Problembericht, der die Ausgabe der weiter oben genannten Werkzeuge beinhaltet.
@@ -2103,14 +2103,14 @@
Dies wird erreicht, indem die MAC-Adresse der Ethernet-Schnittstelle mit der MAC Adresse der drahtlosen Schnittstelle überschrieben wird.
[NOTE]
-****
+====
Theoretisch kann die Ethernet- oder die drahtlose MAC-Adresse so geändert werden, dass sie mit der jeweils anderen Adresse übereinstimmt. Bei einigen drahtlosen Schnittstellen fehlt jedoch die Unterstützung für das Überschreiben der MAC-Adresse. Daher wird empfohlen, die MAC-Adresse der Ethernet-Schnittstelle für diesen Zweck zu überschreiben.
-****
+====
[NOTE]
-****
+====
Wenn der Treiber für die drahtlose Schnittstelle nicht im `GENERIC`-Kernel oder in einem angepassten Kernel enthalten ist, kann unter FreeBSD {rel121-current} mit `_driver__load="YES"` die entsprechende [.filename]#.ko#-Datei in [.filename]#/boot/loader.conf# geladen werden. Dann muss das System neu gestartet werden. Ein anderer, besserer Weg ist es, den Treiber über [.filename]#/etc/rc.conf# zu laden, indem Sie ihn zu `kld_list` (siehe man:rc.conf[5]) hinzufügen und dann das System neu starten. Dies ist notwendig, da sonst der Treiber zum Zeitpunkt der Konfiguration der man:lagg[4]-Schnittstelle noch nicht geladen ist.
-****
+====
In diesem Beispiel ist die Ethernet-Schnittstelle _re0_ der Master und die drahtlose Schnittstelle _wlan0_ der Failover. Die Schnittstelle _wlan0_ wurde aus der physischen Schnittstelle _ath0_ erstellt, und die Ethernet-Schnittstelle wird mit der MAC-Adresse der drahtlosen Schnittstelle konfiguriert. Im ersten Schritt wird die MAC-Adresse der drahtlosen Schnittstelle ermittelt:
@@ -2231,7 +2231,7 @@
....
nfs_server_enable="YES"
....
-+
++
Exportieren Sie das Root-Verzeichnis über NFS, indem Sie folgende Zeile in [.filename]#/etc/exports# hinzufügen:
+
[.programlisting]
@@ -2289,7 +2289,7 @@
# Device Mountpoint FSType Options Dump Pass$
myhost.example.com:/b/tftpboot/FreeBSD/install / nfs ro 0 0
....
-+
++
Ersetzen Sie _myhost.example.com_ durch den Hostnamen oder die IP-Adresse des NFS-Servers. In diesem Beispiel wird das Root-Dateisystem schreibgeschützt eingehangen, um ein potenzielles Löschen des Inhalts durch die NFS-Clients zu verhindern.
. Setzen Sie das root-Passwort in der PXE-Umgebung für Client-Maschinen, die über PXE starten:
+
@@ -2384,7 +2384,7 @@
tftp> get FreeBSD/install/boot/pxeboot
Received 264951 bytes in 0.1 seconds
....
-+
++
Weitere Informationen finden Sie in man:tftpd[8] und man:tftp[1]. Die `BUGS`-Sektionen dieser Seiten dokumentieren einige Einschränkungen von TFTP.
. Achten Sie darauf, dass Sie das Root-Dateisystem über NFS einhängen können. Auch hier können Sie Ihre Einstellungen aus [.filename]#/usr/local/etc/dhcpd.conf# wie folgt testen:
+
diff --git a/documentation/content/en/books/dev-model/_index.adoc b/documentation/content/en/books/dev-model/_index.adoc
--- a/documentation/content/en/books/dev-model/_index.adoc
+++ b/documentation/content/en/books/dev-model/_index.adoc
@@ -79,7 +79,7 @@
However, a project model summarising how the project is structured is needed because of the increasing amount of project members.
footnote:[This goes hand-in-hand with Brooks' law that adding another person to a late project will make it later since it will increase the communication needs . A project model is a tool to reduce the communication needs.]
This paper will provide such a project model and is donated to the FreeBSD Documentation project where it can evolve together with the project so that it can at any point in time reflect the way the project works.
-It is based on [crossref:dev-model[thesis, Saers,2003]].
+It is based on [ crossref:dev-model[thesis, Saers 2003] ].
I would like to thank the following people for taking the time to explain things that were unclear to me and for proofreading the document.
@@ -102,23 +102,23 @@
[[overview]]
== Overview
A project model is a means to reduce the communications overhead in a project.
-As shown by [crossref:dev-model[brooks, Brooks, 1995]], increasing the number of project participants increases the communication in the project exponentially.
+As shown by [ crossref:dev-model[brooks, Brooks 1995] ], increasing the number of project participants increases the communication in the project exponentially.
FreeBSD has during the past few years increased both its mass of active users and committers, and the communication in the project has risen accordingly.
This project model will serve to reduce this overhead by providing an up-to-date description of the project.
During the Core elections in 2002, Mark Murray stated "I am opposed to a long rule-book, as that satisfies lawyer-tendencies, and is counter to the technocentricity that the project so badly needs."
-[crossref:dev-model[bsd-election2002, FreeBSD, 2002B]].
+[ crossref:dev-model[bsd-election2002, FreeBSD 2002B] ].
This project model is not meant to be a tool to justify creating impositions for developers, but as a tool to facilitate coordination.
It is meant as a description of the project, with an overview of how the different processes are executed.
It is an introduction to how the FreeBSD project works.
The FreeBSD project model will be described as of July 1st, 2004.
-It is based on the Niels Jørgensen's paper [crossref:dev-model[jorgensen2001, Jørgensen, 2001]], FreeBSD's official documents, discussions on FreeBSD mailing lists and interviews with developers.
+It is based on the Niels Jørgensen's paper [ crossref:dev-model[jorgensen2001, Jørgensen 2001] ], FreeBSD's official documents, discussions on FreeBSD mailing lists and interviews with developers.
After providing definitions of terms used, this document will outline the organisational structure (including role descriptions and communication lines), discuss the methodology model and after presenting the tools used for process control, it will present the defined processes.
Finally it will outline major sub-projects of the FreeBSD project.
-[crossref:dev-model[freebsd-developer-handbook, FreeBSD, 2002A]] Section 1.2 and 1.3 give the vision and the architectural guidelines for the project.
+[ crossref:dev-model[freebsd-developer-handbook, FreeBSD 2002A] ] Section 1.2 and 1.3 give the vision and the architectural guidelines for the project.
The vision is "To produce the best UNIX-like operating system package possible, with due respect to the original software tools ideology as well as usability, performance and stability."
The architectural guidelines help determine whether a problem that someone wants to be solved is within the scope of the project
@@ -129,7 +129,7 @@
=== Activity
An "activity" is an element of work performed during the course of a project
-[crossref:dev-model[ref-pmbok, PMI, 2000]].
+[ crossref:dev-model[ref-pmbok, PMI 2000] ].
It has an output and leads towards an outcome.
Such an output can either be an input to another activity or a part of the process' delivery.
@@ -155,7 +155,7 @@
This is synonymous with deliverable, that is defined as "any measurable, tangible, verifiable outcome, result or item that must be produced to complete a project or part of a project.
Often used more narrowly in reference to an external deliverable, which is a
deliverable that is subject to approval by the project sponsor or customer" by
-[crossref:dev-model[ref-pmbok, PMI, 2000]].
+[ crossref:dev-model[ref-pmbok, PMI 2000] ].
Examples of outcomes are a piece of software, a decision made or a report written.
[[ref-freebsd]]
@@ -308,7 +308,7 @@
|===
The "development release" is the FreeBSD-CURRENT ("-CURRENT") branch and the
-"production release" is the FreeBSD-STABLE branch ("-STABLE") [crossref:dev-model[jorgensen2001, Jørgensen, 2001]].
+"production release" is the FreeBSD-STABLE branch ("-STABLE") [ crossref:dev-model[jorgensen2001, Jørgensen 2001] ].
This is a model for one change, and shows that after coding, developers seek community review and try integrating it with their own systems.
After integrating the change into the development release, called FreeBSD-CURRENT, it is tested by many users and developers in the FreeBSD community.
@@ -400,7 +400,7 @@
|===
The latest -CURRENT version is always referred to as -CURRENT, while the latest -STABLE release is always referred to as -STABLE.
-In this figure, -STABLE refers to 4-STABLE while -CURRENT refers to 5.0-CURRENT following 5.0-RELEASE. [crossref:dev-model[freebsd-releng, FreeBSD, 2002E]]
+In this figure, -STABLE refers to 4-STABLE while -CURRENT refers to 5.0-CURRENT following 5.0-RELEASE. [ crossref:dev-model[freebsd-releng, FreeBSD 2002E] ]
A "major release" is always made from the -CURRENT branch.
However, the -CURRENT branch does not need to fork at that point in time, but can focus on stabilising.
@@ -460,14 +460,14 @@
A Contributor contributes to the FreeBSD project either as a developer, as an
author, by sending problem reports, or in other ways contributing to the
-progress of the project. A contributor has no special privileges in the FreeBSD project. [crossref:dev-model[freebsd-contributors, FreeBSD, 2002F]]
+progress of the project. A contributor has no special privileges in the FreeBSD project. [ crossref:dev-model[freebsd-contributors, FreeBSD 2002F] ]
[[role-committer]]
==== Committer
A person who has the required privileges to add their code or documentation to the repository.
A committer has made a commit within the past 12 months.
-[crossref:dev-model[freebsd-developer-handbook, FreeBSD, 2000A]] An active committer is a committer who has made an average of one commit per month during that time.
+[ crossref:dev-model[freebsd-developer-handbook, FreeBSD 2000A] ] An active committer is a committer who has made an average of one commit per month during that time.
It is worth noting that there are no technical barriers to prevent someone, once having gained commit privileges to the main- or a sub-project, to make commits in parts of that project's source the committer did not specifically get permission to modify.
However, when wanting to make modifications to parts a committer has not been involved in before, they should read the logs to see what has happened in this area before, and also read the MAINTAINERS file to see if the maintainer of this part has any special requests on how changes in the code should be made.
@@ -707,7 +707,7 @@
Recall that a committer is considered to be someone who has committed code during the past 12 months.
However, it is not until after 18 months of inactivity have passed that commit privileges are eligible to be revoked.
-[crossref:dev-model[freebsd-expiration-policy, FreeBSD, 2002H]]
+[ crossref:dev-model[freebsd-expiration-policy, FreeBSD 2002H] ]
There are, however, no automatic procedures for doing this.
For reactions concerning commit privileges not triggered by time, see
crossref:dev-model[process-reactions,section 1.5.8].
@@ -729,9 +729,9 @@
. crossref:dev-model[role-maintainer, Maintainership]
. crossref:dev-model[role-mentor, Mentor]
-[crossref:dev-model[freebsd-bylaws, FreeBSD, 2000A]]
-[crossref:dev-model[freebsd-expiration-policy, FreeBSD, 2002H]]
-[crossref:dev-model[freebsd-new-account, FreeBSD, 2002I]]
+[ crossref:dev-model[freebsd-bylaws, FreeBSD 2000A] ]
+[ crossref:dev-model[freebsd-expiration-policy, FreeBSD 2002H] ]
+[ crossref:dev-model[freebsd-new-account, FreeBSD 2002I] ]
[[committing]]
=== Committing code
@@ -782,8 +782,8 @@
. crossref:dev-model[role-vendor, Vendor]
. crossref:dev-model[role-reviewer, Reviewers]
-[crossref:dev-model[freebsd-committer, FreeBSD, 2001]]
-[crossref:dev-model[jorgensen2001, Jørgensen, 2001]]
+[ crossref:dev-model[freebsd-committer, FreeBSD 2001] ]
+[ crossref:dev-model[jorgensen2001, Jørgensen 2001] ]
[[process-core-election]]
=== Core election
@@ -824,16 +824,16 @@
* crossref:dev-model[role-committer, Committer]
* crossref:dev-model[role-election-manager, Election Manager]
-[crossref:dev-model[freebsd-bylaws, FreeBSD, 2000A]]
-[crossref:dev-model[bsd-election2002, FreeBSD, 2002B]]
-[crossref:dev-model[freebsd-election, FreeBSD, 2002G]]
+[ crossref:dev-model[freebsd-bylaws, FreeBSD 2000A] ]
+[ crossref:dev-model[bsd-election2002, FreeBSD 2002B] ]
+[ crossref:dev-model[freebsd-election, FreeBSD 2002G] ]
[[new-features]]
=== Development of new features
Within the project there are sub-projects that are working on new features.
These projects are generally done by one person
-[crossref:dev-model[jorgensen2001, Jørgensen, 2001]].
+[ crossref:dev-model[jorgensen2001, Jørgensen 2001] ].
Every project is free to organise development as it sees fit.
However, when the project is merged to the -CURRENT branch it must follow the project guidelines.
When the code has been well tested in the -CURRENT branch and deemed stable enough and relevant to the -STABLE branch, it is merged to the -STABLE branch.
@@ -870,7 +870,7 @@
The maintainer's job is to make sure the code is in sync with the project the code comes from if it is contributed code, and apply patches submitted by the community or write fixes to issues that are discovered.
The main bulk of work that is put into the FreeBSD project is maintenance.
-[crossref:dev-model[jorgensen2001, Jørgensen, 2001]] has made a figure showing the life cycle of changes.
+[ crossref:dev-model[jorgensen2001, Jørgensen 2001] ] has made a figure showing the life cycle of changes.
Jørgenssen's model for change integration
@@ -952,13 +952,13 @@
. crossref:dev-model[role-maintainer, Maintainership]
. crossref:dev-model[role-bugbuster, Bugbuster]
-[crossref:dev-model[freebsd-handle-pr, FreeBSD, 2002C]].
-[crossref:dev-model[freebsd-send-pr, FreeBSD, 2002D]]
+[ crossref:dev-model[freebsd-handle-pr, FreeBSD 2002C] ].
+[ crossref:dev-model[freebsd-send-pr, FreeBSD 2002D] ].
[[process-reactions]]
=== Reacting to misbehavior
-[crossref:dev-model[freebsd-committer, FreeBSD, 2001]] has a number of rules that committers should follow.
+[ crossref:dev-model[freebsd-committer, FreeBSD 2001] ] has a number of rules that committers should follow.
However, it happens that these rules are broken.
The following rules exist in order to be able to react to misbehavior.
They specify what actions will result in how long a suspension of the committer's commit privileges.
@@ -968,7 +968,7 @@
* Commit wars - 5 days to all participating parties
* Impolite or inappropriate behavior - 5 days
-[crossref:dev-model[ref-freebsd-trenches, Lehey, 2002]]
+[ crossref:dev-model[ref-freebsd-trenches, Lehey 2002] ]
For the suspensions to be efficient, any single core member can implement a suspension before discussing it on the "core" mailing list.
Repeat offenders can, with a 2/3 vote by core, receive harsher penalties, including permanent removal of commit privileges.
@@ -1074,7 +1074,7 @@
It is also used for many mailing lists set up and used by other people and projects in the FreeBSD community.
General lists are lists for the general public, technical lists are mainly for the development of specific areas of interest, and closed lists are for internal communication not intended for the general public.
The majority of all the communication in the project goes through these 85 lists
-[crossref:dev-model[ref-bsd-handbook, FreeBSD, 2003A], Appendix C].
+[ crossref:dev-model[ref-bsd-handbook, FreeBSD 2003A], Appendix C].
[[tool-pgp]]
=== Pretty Good Privacy
@@ -1142,7 +1142,7 @@
Like the ports sub-project, the Documentation project can appoint documentation
committers without FreeBSD Core's approval.
-[crossref:dev-model[freebsd-doceng-charter, FreeBSD, 2003B]].
+[ crossref:dev-model[freebsd-doceng-charter, FreeBSD 2003B] ].
The Documentation project has extref:{fdp-primer}[a primer].
This is used both to introduce new project members to the standard tools and syntaxes and to act as a reference when working on the project.
diff --git a/documentation/content/en/books/developers-handbook/secure/_index.adoc b/documentation/content/en/books/developers-handbook/secure/_index.adoc
--- a/documentation/content/en/books/developers-handbook/secure/_index.adoc
+++ b/documentation/content/en/books/developers-handbook/secure/_index.adoc
@@ -1,6 +1,6 @@
---
title: Chapter 3. Secure Programming
-authors:
+authors:
- author: Murray Stokely
prev: books/developers-handbook/tools
next: books/developers-handbook/l10n
@@ -157,7 +157,7 @@
Let us examine what the memory image of this process would look like if we were to input 160 spaces into our little program before hitting return.
-[XXX figure here!]
+[ XXX figure here! ]
Obviously more malicious input can be devised to execute actual compiled instructions (such as exec(/bin/sh)).
diff --git a/documentation/content/en/books/handbook/advanced-networking/_index.adoc b/documentation/content/en/books/handbook/advanced-networking/_index.adoc
--- a/documentation/content/en/books/handbook/advanced-networking/_index.adoc
+++ b/documentation/content/en/books/handbook/advanced-networking/_index.adoc
@@ -136,7 +136,7 @@
subnet::
FreeBSD will automatically add subnet routes for the local subnet.
-In this example, `10.20.30.255` is the broadcast address for the subnet `10.20.30` and `example.com` is the domain name associated with that subnet.
+In this example, `10.20.30.255` is the broadcast address for the subnet `10.20.30` and `example.com` is the domain name associated with that subnet.
The designation `link#1` refers to the first Ethernet card in the machine.
+
Local network hosts and local subnets have their routes automatically configured by a daemon called man:routed[8].
@@ -1109,7 +1109,7 @@
The default name for the L2CAP node is "devicel2cap".
For more details refer to man:ng_l2cap[4].
-A useful command is man:l2ping[8], which can be used to ping other devices.
+A useful command is man:l2ping[8], which can be used to ping other devices.
Some Bluetooth implementations might not return all of the data sent to them, so `0 bytes` in the following example is normal.
[source,shell]
@@ -1164,7 +1164,7 @@
RFCOMM is intended to cover applications that make use of the serial ports of the devices in which they reside.
The communication segment is a direct connect Bluetooth link from one device to another.
-RFCOMM is only concerned with the connection between the devices in the direct connect case, or between the device and a modem in the network case.
+RFCOMM is only concerned with the connection between the devices in the direct connect case, or between the device and a modem in the network case.
RFCOMM can support other configurations, such as modules that communicate via Bluetooth wireless technology on one side and provide a wired interface on the other side.
In FreeBSD, RFCOMM is implemented at the Bluetooth sockets layer.
@@ -1857,18 +1857,18 @@
This is achieved by overriding the Ethernet interface's MAC address with that of the wireless interface.
[NOTE]
-****
+====
In theory, either the Ethernet or wireless MAC address can be changed to match the other.
However, some popular wireless interfaces lack support for overriding the MAC address.
We therefore recommend overriding the Ethernet MAC address for this purpose.
-****
+====
[NOTE]
-****
+====
If the driver for the wireless interface is not loaded in the `GENERIC` or custom kernel, and the computer is running FreeBSD {rel121-current}, load the corresponding [.filename]#.ko# in [.filename]#/boot/loader.conf# by adding `*driver_load="YES"*` to that file and rebooting.
Another, better way is to load the driver in [.filename]#/etc/rc.conf# by adding it to `kld_list` (see man:rc.conf[5] for details) in that file and rebooting.
This is needed because otherwise the driver is not loaded yet at the time the man:lagg[4] interface is set up.
-****
+====
In this example, the Ethernet interface, _re0_, is the master and the wireless interface, _wlan0_, is the failover.
The _wlan0_ interface was created from the _ath0_ physical wireless interface, and the Ethernet interface will be configured with the MAC address of the wireless interface.
diff --git a/documentation/content/en/books/handbook/wayland/_index.adoc b/documentation/content/en/books/handbook/wayland/_index.adoc
--- a/documentation/content/en/books/handbook/wayland/_index.adoc
+++ b/documentation/content/en/books/handbook/wayland/_index.adoc
@@ -641,7 +641,7 @@
There will be some configuration hints presented, the import steps are to add the following lines to [.filename]#/etc/gettytab#:
-[programlisting]
+[.programlisting]
....
Ly:\
:lo=/usr/local/bin/ly:\
@@ -650,7 +650,7 @@
And then modify the ttyv1 line in [.filename]#/etc/ttys# to match the following line:
-[programlisting]
+[.programlisting]
....
ttyv1 "/usr/libexec/getty Ly" xterm onifexists secure
....
diff --git a/documentation/content/en/books/porters-handbook/makefiles/_index.adoc b/documentation/content/en/books/porters-handbook/makefiles/_index.adoc
--- a/documentation/content/en/books/porters-handbook/makefiles/_index.adoc
+++ b/documentation/content/en/books/porters-handbook/makefiles/_index.adoc
@@ -134,10 +134,10 @@
<.> `1.2` is before `1.2p1` as `2p1`, think "2, patch level 1" which is a version after any `2.X` but before `3`.
[NOTE]
-****
+=====
In here, the `a`, `b`, and `p` are used as if meaning "alpha", "beta" or "pre-release" and "patch level",
but they are only letters and are sorted alphabetically, so any letter can be used, and they will be sorted appropriately.
-****
+=====
====
@@ -1546,9 +1546,9 @@
It will automatically have `MASTER_SITES` set to `GH` and `WRKSRC` to `${WRKDIR}/pkg-6dbb17b`.
[TIP]
-****
+====
`20260626` is the date of the commit referenced in `GH_TAGNAME`, not the date the [.filename]#Makefile# is edited, or the date the commit is made.
-****
+====
====
@@ -1645,7 +1645,7 @@
....
[NOTE]
-****
+=====
If the requested commit is the same as a tag, a shorter description is shown by default.
The longer version is equivalent:
@@ -1658,7 +1658,7 @@
v0.7.3-0-gc66c71d
....
-****
+=====
====
@@ -1851,11 +1851,11 @@
Each subdirectory that is a submodule is shown as `_directory @ hash_`, for example, `mongoose @ 2140e59`.
[NOTE]
-****
+=====
While getting the information from GitHub seems more straightforward, the information found using `git submodule status` will provide more meaningful information.
For example, here, ``lib/wxsqlite3``'s commit hash `fb66eb2` correspond to `v3.4.0`.
Both can be used interchangeably, but when a tag is available, use it.
-****
+=====
Now that all the required information has been gathered, the [.filename]#Makefile# can be written (only GitHub-related lines are shown):
diff --git a/documentation/content/en/books/porters-handbook/pkg-files/_index.adoc b/documentation/content/en/books/porters-handbook/pkg-files/_index.adoc
--- a/documentation/content/en/books/porters-handbook/pkg-files/_index.adoc
+++ b/documentation/content/en/books/porters-handbook/pkg-files/_index.adoc
@@ -218,10 +218,10 @@
....
[IMPORTANT]
-****
+=====
When displaying a message on upgrade, it is important to limit when it is being shown to the user.
Most of the time it is by using `maximum_version` to limit its usage to upgrades from before a certain version when something specific needs to be done.
-****
+=====
====
diff --git a/documentation/content/en/books/porters-handbook/quick-porting/_index.adoc b/documentation/content/en/books/porters-handbook/quick-porting/_index.adoc
--- a/documentation/content/en/books/porters-handbook/quick-porting/_index.adoc
+++ b/documentation/content/en/books/porters-handbook/quick-porting/_index.adoc
@@ -284,9 +284,9 @@
easier for developers to apply (with `git am`) and give proper credit.
[IMPORTANT]
-****
+====
To make it easier for committers to apply the patch on their working copy of the ports tree, please generate the [.filename]#.diff# from the base of your ports tree.
-****
+====
====
diff --git a/documentation/content/en/books/porters-handbook/testing/_index.adoc b/documentation/content/en/books/porters-handbook/testing/_index.adoc
--- a/documentation/content/en/books/porters-handbook/testing/_index.adoc
+++ b/documentation/content/en/books/porters-handbook/testing/_index.adoc
@@ -603,9 +603,9 @@
DEFAULT_VERSIONS+= perl=5.20
....
[NOTE]
-****
+=====
Note the use of `+=` so that if the variable is already set in the default [.filename]#make.conf# its content will not be overwritten.
-****
+=====
====
diff --git a/documentation/content/es/books/handbook/advanced-networking/_index.adoc b/documentation/content/es/books/handbook/advanced-networking/_index.adoc
--- a/documentation/content/es/books/handbook/advanced-networking/_index.adoc
+++ b/documentation/content/es/books/handbook/advanced-networking/_index.adoc
@@ -1575,14 +1575,14 @@
Esto se consigue sobrescribiendo la dirección MAC del interfaz Ethernet con el de la interfaz inalámbrica.
[NOTE]
-****
+====
En teoría, cualquiera de las dos direcciones MAC (Ethernet o inalámbrica) se puede cambiar para igualarse a la otra. Sin embargo, algunas interfaces inalámbricas populares carecen del soporte para sobrescribir la dirección MAX. Por lo tanto para este propósito recomendamos sobrescribir la dirección MAC Ethernet.
-****
+====
[NOTE]
-****
+====
Si el controlador para el interfaz inalámbrico no está cargado en el kernel `GENERIC` o en el personalizado, y el ordenador está ejecutando FreeBSD{rel121-current}, carga el [.filename]#.ko# correspondiente en [.filename]#/boot/loader.conf# añadiendo `*driver_load="YES"*` a ese fichero y después reiniciando. Otra forma mejor es cargar el driver en [.filename]#/etc/rc.conf# añadiéndolo a `kld_list` (consulta man:rc.conf[5] para los detalles) en ese fichero y reiniciando. Esto es necesario porque de otra forma el controlador no está todavía cargado en el momento en el que se configura el interfaz man:lagg[4].
-****
+====
En este ejemplo, el interfaz Ethernet, _re0_, es el maestro y el interfaz inalámbrico, _wlan0_, es el recambio. El interfaz _wlan0_ ha sido creado a partir del interfaz inalámbrico físico _ath0_, y el interfaz Ethernet se configurará con la dirección MAC del interfaz inalámbrico. Primero, levanta el interfaz inalámbrico (reemplaza _FR_ con tu código de país de dos letras), pero no establezcas una dirección IP. Reemplaza _wlan0_ con el nombre del interfaz inalámbrico del sistema:
diff --git a/documentation/content/pl/books/handbook/advanced-networking/_index.adoc b/documentation/content/pl/books/handbook/advanced-networking/_index.adoc
--- a/documentation/content/pl/books/handbook/advanced-networking/_index.adoc
+++ b/documentation/content/pl/books/handbook/advanced-networking/_index.adoc
@@ -304,16 +304,16 @@
....
% ifconfig | grep -B3 -i wireless
....
-+
++
On FreeBSD 11 or higher, use this command instead:
+
[source,shell]
....
% sysctl net.wlan.devices
....
-+
++
If a wireless adapter is not listed, an additional kernel module might be required, or it might be a model not supported by FreeBSD.
-+
++
This example shows the Atheros `ath0` wireless adapter.
. Add an entry for this network to [.filename]#/etc/wpa_supplicant.conf#. If the file does not exist, create it. Replace _myssid_ and _mypsk_ with the SSID and PSK provided by the network administrator.
+
@@ -1226,7 +1226,7 @@
* If the access point is not listed when scanning, check that the configuration has not limited the wireless device to a limited set of channels.
* If the device cannot associate with an access point, verify that the configuration matches the settings on the access point. This includes the authentication scheme and any security protocols. Simplify the configuration as much as possible. If using a security protocol such as WPA or WEP, configure the access point for open authentication and no security to see if traffic will pass.
-+
++
Debugging support is provided by man:wpa_supplicant[8]. Try running this utility manually with `-dd` and look at the system logs.
* Once the system can associate with the access point, diagnose the network configuration using tools like man:ping[8].
* There are many lower-level debugging tools. Debugging messages can be enabled in the 802.11 protocol support layer using man:wlandebug[8]. For example, to enable console messages related to scanning for access points and the 802.11 protocol handshakes required to arrange communication:
@@ -1236,7 +1236,7 @@
# wlandebug -i wlan0 +scan+auth+debug+assoc
net.wlan.0.debug: 0 => 0xc80000<assoc,auth,scan>
....
-+
++
Many useful statistics are maintained by the 802.11 layer and `wlanstats`, found in [.filename]#/usr/src/tools/tools/net80211#, will dump this information. These statistics should display all errors identified by the 802.11 layer. However, some errors are identified in the device drivers that lie below the 802.11 layer so they may not show up. To diagnose device-specific problems, refer to the drivers' documentation.
If the above information does not help to clarify the problem, submit a problem report and include output from the above tools.
@@ -2075,14 +2075,14 @@
This is achieved by overriding the Ethernet interface's MAC address with that of the wireless interface.
[NOTE]
-****
+====
In theory, either the Ethernet or wireless MAC address can be changed to match the other. However, some popular wireless interfaces lack support for overriding the MAC address. We therefore recommend overriding the Ethernet MAC address for this purpose.
-****
+====
[NOTE]
-****
+====
If the driver for the wireless interface is not loaded in the `GENERIC` or custom kernel, and the computer is running FreeBSD {rel121-current}, load the corresponding [.filename]#.ko# in [.filename]#/boot/loader.conf# by adding `*driver_load="YES"*` to that file and rebooting. Another, better way is to load the driver in [.filename]#/etc/rc.conf# by adding it to `kld_list` (see man:rc.conf[5] for details) in that file and rebooting. This is needed because otherwise the driver is not loaded yet at the time the man:lagg[4] interface is set up.
-****
+====
In this example, the Ethernet interface, _re0_, is the master and the wireless interface, _wlan0_, is the failover. The _wlan0_ interface was created from the _ath0_ physical wireless interface, and the Ethernet interface will be configured with the MAC address of the wireless interface. First, determine the MAC address of the wireless interface:
@@ -2261,7 +2261,7 @@
# Device Mountpoint FSType Options Dump Pass
myhost.example.com:/b/tftpboot/FreeBSD/install / nfs ro 0 0
....
-+
++
Replace _myhost.example.com_ with the hostname or IP address of the NFS server. In this example, the root file system is mounted read-only in order to prevent NFS clients from potentially deleting the contents of the root file system.
. Set the root password in the PXE environment for client machines which are PXE booting :
+
@@ -2368,7 +2368,7 @@
tftp> get FreeBSD/install/boot/pxeboot
Received 264951 bytes in 0.1 seconds
....
-+
++
The `BUGS` sections in man:tftpd[8] and man:tftp[1] document some limitations with TFTP.
. Make sure that the root file system can be mounted via NFS. To test this example configuration:
+
diff --git a/documentation/content/ru/books/dev-model/_index.adoc b/documentation/content/ru/books/dev-model/_index.adoc
--- a/documentation/content/ru/books/dev-model/_index.adoc
+++ b/documentation/content/ru/books/dev-model/_index.adoc
@@ -1,6 +1,6 @@
---
authors:
- -
+ -
author: 'Niklas Saers'
bookOrder: 45
copyright: '2002-2005 Niklas Saers'
@@ -76,7 +76,7 @@
[.abstract-title]
Предисловие
-До настоящего момента проект FreeBSD выпустил ряд описанных методик для выполнения различных частей работы. Однако, из-за растущего числа участников проекта, необходима модель проекта, обобщающая его структуру. footnote:[Это согласуется с законом Брукса, согласно которому добавление нового человека в задерживающийся проект сделает его ещё более задержанным, поскольку увеличит потребность в коммуникации. Модель проекта — это инструмент для снижения потребности в коммуникации.] Данная статья предоставляет такую модель проекта и передаётся в проект документации FreeBSD, где она может развиваться вместе с проектом, чтобы в любой момент времени отражать способ его работы. Она основана на диссертации [crossref:dev-model[thesis, Saers,2003]].
+До настоящего момента проект FreeBSD выпустил ряд описанных методик для выполнения различных частей работы. Однако, из-за растущего числа участников проекта, необходима модель проекта, обобщающая его структуру. footnote:[Это согласуется с законом Брукса, согласно которому добавление нового человека в задерживающийся проект сделает его ещё более задержанным, поскольку увеличит потребность в коммуникации. Модель проекта — это инструмент для снижения потребности в коммуникации.] Данная статья предоставляет такую модель проекта и передаётся в проект документации FreeBSD, где она может развиваться вместе с проектом, чтобы в любой момент времени отражать способ его работы. Она основана на диссертации [ crossref:dev-model[thesis, Saers,2003]].
Я хотел бы поблагодарить следующих людей за то, что они нашли время объяснить мне непонятные моменты и проверить документ.
@@ -98,15 +98,15 @@
[[overview]]
== Обзор
-Модель проекта — это способ снижения накладных расходов на коммуникации в проекте. Как показано в [crossref:dev-model[brooks, Brooks, 1995]], увеличение числа участников проекта приводит к экспоненциальному росту коммуникаций в проекте. За последние годы FreeBSD значительно увеличил как количество активных пользователей, так и коммиттеров, что соответственно привело к росту коммуникаций. Данная модель проекта поможет снизить эти накладные расходы за счёт предоставления актуального описания проекта.
+Модель проекта — это способ снижения накладных расходов на коммуникации в проекте. Как показано в [ crossref:dev-model[brooks, Brooks, 1995]], увеличение числа участников проекта приводит к экспоненциальному росту коммуникаций в проекте. За последние годы FreeBSD значительно увеличил как количество активных пользователей, так и коммиттеров, что соответственно привело к росту коммуникаций. Данная модель проекта поможет снизить эти накладные расходы за счёт предоставления актуального описания проекта.
-Во время выборов в Core в 2002 году Марк Мюррей заявил: «Я против длинного свода правил, так как это удовлетворяет склонности к юриспруденции и противоречит техноцентричности, в которой проект так нуждается.» [crossref:dev-model[bsd-election2002, FreeBSD, 2002B]]. Эта модель проекта не предназначена для того, чтобы оправдывать создание ограничений для разработчиков, а служит инструментом для облегчения координации. Она призвана описывать проект, давая обзор того, как выполняются различные процессы. Это введение в то, как работает проект FreeBSD.
+Во время выборов в Core в 2002 году Марк Мюррей заявил: «Я против длинного свода правил, так как это удовлетворяет склонности к юриспруденции и противоречит техноцентричности, в которой проект так нуждается.» [ crossref:dev-model[bsd-election2002, FreeBSD, 2002B]]. Эта модель проекта не предназначена для того, чтобы оправдывать создание ограничений для разработчиков, а служит инструментом для облегчения координации. Она призвана описывать проект, давая обзор того, как выполняются различные процессы. Это введение в то, как работает проект FreeBSD.
-Модель проекта FreeBSD будет описана по состоянию на 1 июля 2004 года. Она основана на работе Нильса Йоргенсена [crossref:dev-model[jorgensen2001, Jørgensen, 2001]], официальных документах FreeBSD, обсуждениях в списках рассылки FreeBSD и интервью с разработчиками.
+Модель проекта FreeBSD будет описана по состоянию на 1 июля 2004 года. Она основана на работе Нильса Йоргенсена [ crossref:dev-model[jorgensen2001, Jørgensen, 2001]], официальных документах FreeBSD, обсуждениях в списках рассылки FreeBSD и интервью с разработчиками.
После определения используемых терминов в этом документе будет описана организационная структура (включая описания ролей и линии коммуникации), рассмотрена модель методологии, а после представления инструментов, используемых для контроля процессов, будут описаны определённые процессы. В заключение будут представлены основные подпроекты проекта FreeBSD.
-[crossref:dev-model[freebsd-developer-handbook, FreeBSD, 2002A]] Разделы 1.2 и 1.3 описывают видение и архитектурные принципы проекта. Видение сформулировано как: "Создать наилучший пакет операционной системы, подобной UNIX®, с должным уважением к оригинальной идеологии программных инструментов, а также к удобству использования, производительности и стабильности." Архитектурные принципы помогают определить, находится ли проблема, которую кто-то хочет решить, в рамках проекта
+[ crossref:dev-model[freebsd-developer-handbook, FreeBSD, 2002A]] Разделы 1.2 и 1.3 описывают видение и архитектурные принципы проекта. Видение сформулировано как: "Создать наилучший пакет операционной системы, подобной UNIX®, с должным уважением к оригинальной идеологии программных инструментов, а также к удобству использования, производительности и стабильности." Архитектурные принципы помогают определить, находится ли проблема, которую кто-то хочет решить, в рамках проекта
[[definitions]]
== Определения
@@ -114,7 +114,7 @@
[[ref-activity]]
=== Активность
-"Активность" — это элемент работы, выполняемый в ходе проекта [crossref:dev-model[ref-pmbok, PMI, 2000]]. У неё есть результат, который ведёт к достижению цели. Такой результат может быть либо входом для другой активности, либо частью поставки процесса.
+"Активность" — это элемент работы, выполняемый в ходе проекта [ crossref:dev-model[ref-pmbok, PMI, 2000]]. У неё есть результат, который ведёт к достижению цели. Такой результат может быть либо входом для другой активности, либо частью поставки процесса.
[[def-process]]
=== Процесс
@@ -129,7 +129,7 @@
[[ref-outcome]]
=== Результат
-«Результат» — это конечный продукт процесса. Это синоним понятия «поставляемый результат», который определяется как «любой измеримый, осязаемый, проверяемый результат, итог или элемент, который должен быть произведён для завершения проекта или его части. Часто используется в более узком смысле в отношении внешнего поставляемого результата, который подлежит утверждению спонсором проекта или заказчиком» согласно [crossref:dev-model[ref-pmbok, PMI, 2000]]. Примерами результатов являются программное обеспечение, принятое решение или написанный отчёт.
+«Результат» — это конечный продукт процесса. Это синоним понятия «поставляемый результат», который определяется как «любой измеримый, осязаемый, проверяемый результат, итог или элемент, который должен быть произведён для завершения проекта или его части. Часто используется в более узком смысле в отношении внешнего поставляемого результата, который подлежит утверждению спонсором проекта или заказчиком» согласно [ crossref:dev-model[ref-pmbok, PMI, 2000]]. Примерами результатов являются программное обеспечение, принятое решение или написанный отчёт.
[[ref-freebsd]]
=== FreeBSD
@@ -179,27 +179,27 @@
| Количество людей
|Основные участники
-|
+|
|9
|Коммиттеры
|Базовый
|164
-|
+|
|Docs
|45
-|
+|
|Порты
|166
-|
+|
|Total
|374
|Участники
-|
+|
|~3000
|===
@@ -234,7 +234,7 @@
|программирование
|рецензирование
-|
+|
|рецензирование
|предварительная проверка перед коммитом
@@ -253,11 +253,11 @@
|программирование
|релиз для производства
-|
+|
|программирование
|===
-"Релиз для разработки" — это ветка FreeBSD-CURRENT ("-CURRENT"), а "релиз для производства" — ветка FreeBSD-STABLE ("-STABLE") [crossref:dev-model[jorgensen2001, Jørgensen, 2001]].
+"Релиз для разработки" — это ветка FreeBSD-CURRENT ("-CURRENT"), а "релиз для производства" — ветка FreeBSD-STABLE ("-STABLE") [ crossref:dev-model[jorgensen2001, Jørgensen, 2001]].
Это модель для одного изменения, которая показывает, что после написания кода разработчики ищут рецензирование сообщества и пытаются интегрировать это изменение в свои собственные системы. После интеграции изменения в версию разработки, называемую FreeBSD-CURRENT, оно тестируется многими пользователями и разработчиками сообщества FreeBSD. После достаточного тестирования оно объединяется с производственной версией, называемой FreeBSD-STABLE. Если каждая стадия не завершена успешно, разработчику необходимо вернуться, внести изменения в код и перезапустить процесс. Интеграция изменения в -CURRENT или -STABLE называется выполнением коммита.
@@ -295,11 +295,11 @@
| Следующие минорные выпуски
|...
-|
-|
+|
+|
|3.0 Current (ветка разработки)
-|
+|
|Ветки Releng 3: выпуски с 3.0 Release по 3.5 Release, ведущие к выпуску 3.5.1 Release и последующей ветке 3 Stable
|4.0 Current (ветка разработки)
@@ -312,15 +312,15 @@
|6.0 Current (ветка разработки)
|Релиз 5.3
-|
+|
|...
-|
-|
+|
+|
|===
-Последняя версия -CURRENT всегда обозначается как -CURRENT, а последний релиз -STABLE всегда обозначается как -STABLE. На этом рисунке -STABLE относится к 4-STABLE, а -CURRENT относится к 5.0-CURRENT после 5.0-RELEASE. [crossref:dev-model[freebsd-releng, FreeBSD, 2002E]]
+Последняя версия -CURRENT всегда обозначается как -CURRENT, а последний релиз -STABLE всегда обозначается как -STABLE. На этом рисунке -STABLE относится к 4-STABLE, а -CURRENT относится к 5.0-CURRENT после 5.0-RELEASE. [ crossref:dev-model[freebsd-releng, FreeBSD, 2002E]]
«Основной выпуск» всегда создаётся из ветки -CURRENT. Однако ветка -CURRENT не обязательно должна разветвляться в этот момент, а может сосредоточиться на стабилизации. Примером этого является то, что после 3.0-RELEASE, 3.1-RELEASE также был продолжением ветки -CURRENT, и -CURRENT не стал настоящей веткой разработки до тех пор, пока не был выпущен этот релиз и не была создана ветка 3-STABLE. Когда -CURRENT снова становится веткой разработки, за ним может следовать только основной выпуск. Ожидается, что ветка 5-STABLE будет отделена от 5.0-CURRENT примерно на момент выпуска 5.3-RELEASE. Только после отделения 5-STABLE ветка разработки получит название 6.0-CURRENT.
@@ -357,12 +357,12 @@
[[role-contributor]]
==== Участник (контрибьютор)
-Участник вносит вклад в проект FreeBSD в качестве разработчика, автора, отправляя отчёты о проблемах или другими способами способствуя прогрессу проекта. Участник не имеет особых привилегий в проекте FreeBSD. [crossref:dev-model[freebsd-contributors, FreeBSD, 2002F]]
+Участник вносит вклад в проект FreeBSD в качестве разработчика, автора, отправляя отчёты о проблемах или другими способами способствуя прогрессу проекта. Участник не имеет особых привилегий в проекте FreeBSD. [ crossref:dev-model[freebsd-contributors, FreeBSD, 2002F]]
[[role-committer]]
==== Коммиттер
-Человек, обладающий необходимыми привилегиями для добавления своего кода или документации в репозиторий. Коммиттер совершил коммит в течение последних 12 месяцев. [crossref:dev-model[freebsd-developer-handbook, FreeBSD, 2000A]] Активный коммиттер — это коммиттер, который в среднем совершал один коммит в месяц в течение этого времени.
+Человек, обладающий необходимыми привилегиями для добавления своего кода или документации в репозиторий. Коммиттер совершил коммит в течение последних 12 месяцев. [ crossref:dev-model[freebsd-developer-handbook, FreeBSD, 2000A]] Активный коммиттер — это коммиттер, который в среднем совершал один коммит в месяц в течение этого времени.
Стоит отметить, что нет технических препятствий, которые могли бы помешать кому-либо, получившему права на коммиты в основном или подпроекте, делать коммиты в частях исходного кода проекта, для которых у коммиттера нет явного разрешения на изменение. Однако, при желании внести изменения в части, с которыми коммиттер ранее не работал, следует изучить логи, чтобы понять, что происходило в этой области ранее, а также прочитать файл MAINTAINERS, чтобы узнать, есть ли у сопровождающего этой части какие-либо особые требования к внесению изменений в код.
@@ -553,7 +553,7 @@
Когда участник отправляет фрагмент кода, принимающий коммиттер может предложить предоставить этому участнику права на коммит. Если он рекомендует это основной команде (Core Team), команда проводит голосование по этой рекомендации. Если голосование завершается в пользу предложения, новому коммиттеру назначается наставник, и новый коммиттер должен отправить свои данные администраторам для создания учётной записи. После этого новый коммиттер готов сделать свой первый коммит. По традиции, это делается путём добавления своего имени в список коммиттеров.
Напомним, что коммиттером считается тот, кто за последние 12 месяцев внёс изменения в код. Однако право на коммиты может быть отозвано только после 18 месяцев неактивности.
-[crossref:dev-model[freebsd-expiration-policy, FreeBSD, 2002H]]
+[ crossref:dev-model[freebsd-expiration-policy, FreeBSD, 2002H]]
Однако не существует автоматических процедур для этого. Для действий, связанных с привилегиями коммитов, не вызванных временем, см. crossref:dev-model[process-reactions,раздел 1.5.8].
.Процесс: удаление коммиттера
@@ -571,9 +571,9 @@
. crossref:dev-model[role-maintainer, Сопровождение]
. crossref:dev-model[role-mentor, Наставник (Mentor)]
-[crossref:dev-model[freebsd-bylaws, FreeBSD, 2000A]]
-[crossref:dev-model[freebsd-expiration-policy, FreeBSD, 2002H]]
-[crossref:dev-model[freebsd-new-account, FreeBSD, 2002I]]
+[ crossref:dev-model[freebsd-bylaws, FreeBSD, 2000A]]
+[ crossref:dev-model[freebsd-expiration-policy, FreeBSD, 2002H]]
+[ crossref:dev-model[freebsd-new-account, FreeBSD, 2002I]]
[[committing]]
=== Коммит кода
@@ -605,8 +605,8 @@
. crossref:dev-model[role-vendor, Поставщик]
. crossref:dev-model[role-reviewer, Рецензенты]
-[crossref:dev-model[freebsd-committer, FreeBSD, 2001]]
-[crossref:dev-model[jorgensen2001, Jørgensen, 2001]]
+[ crossref:dev-model[freebsd-committer, FreeBSD, 2001]]
+[ crossref:dev-model[jorgensen2001, Jørgensen, 2001]]
[[process-core-election]]
=== Выборы основной команды (Core Team)
@@ -638,14 +638,14 @@
* crossref:dev-model[role-committer, Коммиттер]
* crossref:dev-model[role-election-manager, Менеджер выборов]
-[crossref:dev-model[freebsd-bylaws, FreeBSD, 2000A]]
-[crossref:dev-model[bsd-election2002, FreeBSD, 2002B]]
-[crossref:dev-model[freebsd-election, FreeBSD, 2002G]]
+[ crossref:dev-model[freebsd-bylaws, FreeBSD, 2000A]]
+[ crossref:dev-model[bsd-election2002, FreeBSD, 2002B]]
+[ crossref:dev-model[freebsd-election, FreeBSD, 2002G]]
[[new-features]]
=== Разработка новых функций
-В рамках проекта существуют подпроекты, работающие над новыми функциями. Эти проекты обычно выполняются одним человеком [crossref:dev-model[jorgensen2001, Йоргенсен, 2001]]. Каждый проект волен организовывать разработку так, как считает нужным. Однако, когда проект объединяется с ветвью -CURRENT, он должен следовать руководствам проекта. Когда код хорошо протестирован в ветви -CURRENT и признан достаточно стабильным и актуальным для ветви -STABLE, он объединяется с ветвью -STABLE.
+В рамках проекта существуют подпроекты, работающие над новыми функциями. Эти проекты обычно выполняются одним человеком [ crossref:dev-model[jorgensen2001, Йоргенсен, 2001]]. Каждый проект волен организовывать разработку так, как считает нужным. Однако, когда проект объединяется с ветвью -CURRENT, он должен следовать руководствам проекта. Когда код хорошо протестирован в ветви -CURRENT и признан достаточно стабильным и актуальным для ветви -STABLE, он объединяется с ветвью -STABLE.
Требования проекта определяются пожеланиями разработчиков, запросами сообщества в виде прямых обращений по почте, отчётов о проблемах (Problem Reports), коммерческим финансированием разработки функциональности или вкладами научного сообщества. Пожелания, которые входят в зону ответственности разработчика, передаются этому разработчику, который расставляет приоритеты между запросом и своими собственными пожеланиями. Распространенный способ организации этого процесса — ведение списка задач (TODO-list), поддерживаемого проектом. Задачи, не входящие в чью-либо зону ответственности, собираются в списках TODO, пока кто-нибудь не возьмет на себя ответственность за их выполнение. Все запросы, их распределение и отслеживание обрабатываются с помощью инструмента crossref:dev-model[tool-bugzilla, Bugzilla].
@@ -660,7 +660,7 @@
Для проекта полезно, чтобы за каждую область исходного кода отвечал хотя бы один человек, который хорошо её знает. Некоторые части кода имеют назначенных сопровождающих. Другие имеют фактических сопровождающих, а некоторые части системы не имеют сопровождающих. Сопровождающий обычно является участником подпроекта, который написал и интегрировал код, или тем, кто портировал его с платформы, для которой он был написан. footnote:[sendmail и named — примеры кода, который был объединён с других платформ.] Задача сопровождающего — убедиться, что код синхронизирован с проектом, из которого он получен, если это сторонний код, а также применять патчи, предоставленные сообществом, или исправлять обнаруженные проблемы.
-Основной объём работы, вкладываемый в проект FreeBSD, связан с сопровождением. [crossref:dev-model[jorgensen2001, Jørgensen, 2001]] предоставляет схему, показывающую жизненный цикл изменений.
+Основной объём работы, вкладываемый в проект FreeBSD, связан с сопровождением. [ crossref:dev-model[jorgensen2001, Jørgensen, 2001]] предоставляет схему, показывающую жизненный цикл изменений.
Модель Йоргенссена для интеграции изменений
@@ -673,7 +673,7 @@
|программирование
|рецензирование
-|
+|
|рецензирование
|предварительная проверка перед коммитом
@@ -692,7 +692,7 @@
|программирование
|релиз для производства
-|
+|
|программирование
|===
@@ -720,20 +720,20 @@
. crossref:dev-model[role-maintainer, Сопровождение]
. crossref:dev-model[role-bugbuster, Исправитель ошибок (Bugbuster)]
-[crossref:dev-model[freebsd-handle-pr, FreeBSD, 2002C]].
-[crossref:dev-model[freebsd-send-pr, FreeBSD, 2002D]]
+[ crossref:dev-model[freebsd-handle-pr, FreeBSD, 2002C]].
+[ crossref:dev-model[freebsd-send-pr, FreeBSD, 2002D]]
[[process-reactions]]
=== Реагирование на неправильное поведение
-[crossref:dev-model[freebsd-committer, FreeBSD, 2001]] содержит ряд правил, которым должны следовать коммиттеры. Однако случается, что эти правила нарушаются. Следующие правила существуют для того, чтобы можно было реагировать на неподобающее поведение. Они определяют, какие действия приведут к приостановке привилегий коммиттера на тот или иной срок.
+[ crossref:dev-model[freebsd-committer, FreeBSD, 2001]] содержит ряд правил, которым должны следовать коммиттеры. Однако случается, что эти правила нарушаются. Следующие правила существуют для того, чтобы можно было реагировать на неподобающее поведение. Они определяют, какие действия приведут к приостановке привилегий коммиттера на тот или иной срок.
* Совершение коммитов во время заморозки кода без одобрения команды Release Engineering — 2 дня
* Коммит изменений в ветку безопасности без одобрения - 2 дня
* Войны коммитов — 5 дней для всех участвующих сторон
* Невежливое или неподобающее поведение — 5 дней
-[crossref:dev-model[ref-freebsd-trenches, Lehey, 2002]]
+[ crossref:dev-model[ref-freebsd-trenches, Lehey, 2002]]
Для эффективности приостановок любой член основной команды (Core Team) может применить приостановку до обсуждения на почтовой рассылке "core". Повторные нарушители могут, при 2/3 голосов от основной команды, получить более строгие наказания, включая постоянное лишение прав на коммиты. (Однако последнее всегда рассматривается как крайняя мера из-за присущей ему склонности вызывать споры.) Все приостановки публикуются в почтовой рассылке "developers", доступной только коммиттерам.
@@ -799,7 +799,7 @@
[[model-mailman]]
=== Mailman
-Mailman - это программа, которая автоматизирует управление почтовыми рассылками. Проект FreeBSD использует её для ведения 16 общих рассылок, 60 технических рассылок, 4 ограниченных рассылок и 5 рассылок с логами коммитов Git. Она также используется для многих почтовых рассылок, созданных и используемых другими людьми и проектами в сообществе FreeBSD. Общие рассылки предназначены для широкой публики, технические рассылки в основном предназначены для разработки определённых областей интересов, а закрытые рассылки используются для внутренней коммуникации, не предназначенной для широкой публики. Большая часть всей коммуникации в проекте проходит через эти 85 рассылок [crossref:dev-model[ref-bsd-handbook, FreeBSD, 2003A], Приложение C].
+Mailman - это программа, которая автоматизирует управление почтовыми рассылками. Проект FreeBSD использует её для ведения 16 общих рассылок, 60 технических рассылок, 4 ограниченных рассылок и 5 рассылок с логами коммитов Git. Она также используется для многих почтовых рассылок, созданных и используемых другими людьми и проектами в сообществе FreeBSD. Общие рассылки предназначены для широкой публики, технические рассылки в основном предназначены для разработки определённых областей интересов, а закрытые рассылки используются для внутренней коммуникации, не предназначенной для широкой публики. Большая часть всей коммуникации в проекте проходит через эти 85 рассылок [ crossref:dev-model[ref-bsd-handbook, FreeBSD, 2003A], Приложение C].
[[tool-pgp]]
=== Pretty Good Privacy
@@ -847,7 +847,7 @@
Как и проект FreeBSD, документация разделена на те же ветви. Это сделано для того, чтобы для каждой версии всегда была обновлённая документация. В ветвях безопасности исправляются только ошибки в документации.
-Как и подпроект ports, проект Documentation может назначать коммиттеров документации без одобрения основной команды FreeBSD (Core Team). [crossref:dev-model[freebsd-doceng-charter, FreeBSD, 2003B]].
+Как и подпроект ports, проект Documentation может назначать коммиттеров документации без одобрения основной команды FreeBSD (Core Team). [ crossref:dev-model[freebsd-doceng-charter, FreeBSD, 2003B]].
Проект документации включает в себя extref:{fdp-primer}[вводное руководство]. Оно используется как для ознакомления новых участников проекта со стандартными инструментами и синтаксисом, так и в качестве справочника при работе над проектом.
diff --git a/documentation/content/ru/books/developers-handbook/secure/_index.adoc b/documentation/content/ru/books/developers-handbook/secure/_index.adoc
--- a/documentation/content/ru/books/developers-handbook/secure/_index.adoc
+++ b/documentation/content/ru/books/developers-handbook/secure/_index.adoc
@@ -1,6 +1,6 @@
---
authors:
- -
+ -
author: 'Murray Stokely'
description: 'Безопасное программирование в FreeBSD'
next: books/developers-handbook/l10n
@@ -78,37 +78,37 @@
|===
|`strcpy`(char *dest, const char *src)
-|
+|
Может переполнить буфер назначения
|`strcat`(char *dest, const char *src)
-|
+|
Может переполнить буфер назначения
|`getwd`(char *buf)
-|
+|
Может переполнить буфер buf
|`gets`(char *s)
-|
+|
Может переполнить буфер s
|`[vf]scanf`(const char *format, ...)
-|
+|
Может переполнить свои аргументы.
|`realpath`(char *path, char resolved_path[])
-|
+|
Может переполнить буфер пути
|`[v]sprintf`(char *str, const char *format, ...)
-|
+|
Может переполнить буфер str.
|===
@@ -142,7 +142,7 @@
Давайте рассмотрим, как будет выглядеть образ памяти этого процесса, если мы введем 160 пробелов в нашу небольшую программу перед нажатием Enter.
-[XXX figure here!]
+[ XXX figure here! ]
Очевидно, что можно разработать более вредоносные входные данные для выполнения реальных скомпилированных инструкций (например, exec(/bin/sh)).
diff --git a/documentation/content/ru/books/handbook/advanced-networking/_index.adoc b/documentation/content/ru/books/handbook/advanced-networking/_index.adoc
--- a/documentation/content/ru/books/handbook/advanced-networking/_index.adoc
+++ b/documentation/content/ru/books/handbook/advanced-networking/_index.adoc
@@ -1584,14 +1584,14 @@
Это достигается путем замены MAC-адреса Ethernet-интерфейса на MAC-адрес беспроводного интерфейса.
[NOTE]
-****
+====
Теоретически, либо Ethernet, либо беспроводной MAC-адрес можно изменить, чтобы они были одинаковыми. Однако некоторые популярные беспроводные интерфейсы не поддерживают переопределение MAC-адреса. Поэтому мы рекомендуем переопределить Ethernet MAC-адрес для этой цели.
-****
+====
[NOTE]
-****
+====
Если драйвер для беспроводного интерфейса не загружен в `GENERIC` или собственном ядре, и компьютер работает под FreeBSD {rel121-current}, загрузите соответствующий [.filename]#.ko# в [.filename]#/boot/loader.conf#, добавив `*driver_load="YES"*` в этот файл и перезагрузив систему. Другой, более предпочтительный способ — загрузить драйвер в [.filename]#/etc/rc.conf#, добавив его в `kld_list` (подробности см. в man:rc.conf[5]) в этом файле и перезагрузив систему. Это необходимо, потому что в противном случае драйвер ещё не загружен к моменту настройки интерфейса man:lagg[4].
-****
+====
В этом примере Ethernet-интерфейс _re0_ является основным, а беспроводной интерфейс _wlan0_ — резервным. Интерфейс _wlan0_ был создан на основе физического беспроводного интерфейса _ath0_, а Ethernet-интерфейс будет настроен с MAC-адресом беспроводного интерфейса. Сначала включите беспроводной интерфейс (замените _FR_ на код вашей страны из 2 букв), но не задавайте IP-адрес. Замените _wlan0_ на имя беспроводного интерфейса вашей системы:
diff --git a/documentation/content/ru/books/handbook/wayland/_index.adoc b/documentation/content/ru/books/handbook/wayland/_index.adoc
--- a/documentation/content/ru/books/handbook/wayland/_index.adoc
+++ b/documentation/content/ru/books/handbook/wayland/_index.adoc
@@ -509,7 +509,7 @@
Будут представлены некоторые подсказки по настройке, основные шаги - добавить следующие строки в [.filename]#/etc/gettytab#:
-[programlisting]
+[.programlisting]
....
Ly:\
:lo=/usr/local/bin/ly:\
@@ -518,7 +518,7 @@
И затем измените строку ttyv1 в файле [.filename]#/etc/ttys#, чтобы она соответствовала следующей строке:
-[programlisting]
+[.programlisting]
....
ttyv1 "/usr/libexec/getty Ly" xterm onifexists secure
....
diff --git a/documentation/content/ru/books/handbook/x11/_index.adoc b/documentation/content/ru/books/handbook/x11/_index.adoc
--- a/documentation/content/ru/books/handbook/x11/_index.adoc
+++ b/documentation/content/ru/books/handbook/x11/_index.adoc
@@ -402,7 +402,7 @@
[TIP]
====
-Пакет <<package,x11/nvidia-xconfig>> также может быть использован для базового управления параметрами конфигурации, доступными в драйвере NVIDIA.
+Пакет package:x11/nvidia-xconfig[] также может быть использован для базового управления параметрами конфигурации, доступными в драйвере NVIDIA.
====
Для настройки драйвера SCFB в файле конфигурации:
@@ -507,27 +507,27 @@
....
Screen 0: minimum 320 x 200, current 2560 x 960, maximum 8192 x 8192
LVDS-1 connected 1280x800+0+0 (normal left inverted right x axis y axis) 261mm x 163mm
- 1280x800 59.99*+ 59.81 59.91 50.00
- 1280x720 59.86 59.74
- 1024x768 60.00
- 1024x576 59.90 59.82
- 960x540 59.63 59.82
- 800x600 60.32 56.25
- 864x486 59.92 59.57
- 640x480 59.94
- 720x405 59.51 58.99
- 640x360 59.84 59.32
+ 1280x800 59.99*+ 59.81 59.91 50.00
+ 1280x720 59.86 59.74
+ 1024x768 60.00
+ 1024x576 59.90 59.82
+ 960x540 59.63 59.82
+ 800x600 60.32 56.25
+ 864x486 59.92 59.57
+ 640x480 59.94
+ 720x405 59.51 58.99
+ 640x360 59.84 59.32
VGA-1 connected primary 1280x960+1280+0 (normal left inverted right x axis y axis) 410mm x 257mm
- 1280x1024 75.02 60.02
- 1440x900 74.98 60.07
- 1280x960 60.00*
- 1280x800 74.93 59.81
- 1152x864 75.00
- 1024x768 75.03 70.07 60.00
- 832x624 74.55
- 800x600 72.19 75.00 60.32 56.25
- 640x480 75.00 72.81 66.67 59.94
- 720x400 70.08
+ 1280x1024 75.02 60.02
+ 1440x900 74.98 60.07
+ 1280x960 60.00*
+ 1280x800 74.93 59.81
+ 1152x864 75.00
+ 1024x768 75.03 70.07 60.00
+ 832x624 74.55
+ 800x600 72.19 75.00 60.32 56.25
+ 640x480 75.00 72.81 66.67 59.94
+ 720x400 70.08
HDMI-1 disconnected (normal left inverted right x axis y axis)
DP-1 disconnected (normal left inverted right x axis y axis)
HDMI-2 disconnected (normal left inverted right x axis y axis)
@@ -597,7 +597,7 @@
Её вывод должен быть похож на следующий:
[example]
-....
+====
⎡ Virtual core pointer id=2 [master pointer (3)]
⎜ ↳ Virtual core XTEST pointer id=4 [slave pointer (2)]
@@ -610,7 +610,7 @@
↳ Power Button id=8 [slave keyboard (3)]
↳ Sleep Button id=9 [slave keyboard (3)]
↳ AT keyboard id=10 [slave keyboard (3)]
-....
+====
Все поддерживаемые этими устройствами настройки предоставляются в виде свойств, которые можно выводить и устанавливать атомарно. Указывающие устройства имеют множество настраиваемых свойств, клавиатурам обычно не требуется ничего.
diff --git a/documentation/content/ru/books/porters-handbook/makefiles/_index.adoc b/documentation/content/ru/books/porters-handbook/makefiles/_index.adoc
--- a/documentation/content/ru/books/porters-handbook/makefiles/_index.adoc
+++ b/documentation/content/ru/books/porters-handbook/makefiles/_index.adoc
@@ -123,9 +123,9 @@
<.> `1.2` находится перед `1.2p1`, так же как `2p1` (читается как "2, уровень исправления 1") — это версия, следующая после любой `2.X`, но перед `3`.
[NOTE]
-****
+=====
Здесь `a`, `b` и `p` используются так, как если бы они означали "альфа", "бета" или "пре-релиз" и "уровень патча", но на самом деле это просто буквы, которые сортируются в алфавитном порядке, поэтому можно использовать любую букву, и они будут отсортированы соответствующим образом.
-****
+=====
====
@@ -439,7 +439,7 @@
|mule
|(пусто)
|2.2.2
-|
+|
|Никаких изменений не требуется
|mule-1.0.1
@@ -447,7 +447,7 @@
|mule
|1
|1.0.1
-|
+|
|Это версия 1 mule, а версия 2 уже существует
|EmiClock-1.0.2
@@ -455,7 +455,7 @@
|emiclock
|(пусто)
|1.0.2
-|
+|
|Нет имён в верхнем регистре для отдельных программ
|rdist-1.3alpha
@@ -463,7 +463,7 @@
|rdist
|(пусто)
|1.3alpha
-|
+|
|Версия будет `1.3.a`
|es-0.9-beta1
@@ -471,7 +471,7 @@
|es
|(пусто)
|0.9-beta1
-|
+|
|Версия будет `0.9.b1`
|mailman-2.0rc3
@@ -479,14 +479,14 @@
|mailman
|(пусто)
|2.0rc3
-|
+|
|Версия будет `2.0.r3`
|v3.3beta021.src
|(пусто)
|tiff
|(пусто)
-|
+|
|3.3
|Что это вообще было?
@@ -494,7 +494,7 @@
|(пусто)
|tvtwm
|(пусто)
-|
+|
|p11
|Нет версии в имени файла, используйте то, что указано в исходном коде
@@ -503,14 +503,14 @@
|piewm
|(пусто)
|1.0
-|
+|
|Нет версии в имени файла, используйте то, что указано в исходном коде
|xvgr-2.10pl1
|(пусто)
|xvgr
|(пусто)
-|
+|
|2.10.pl1
|В таком случае, `pl1` означает уровень патча, поэтому использование DISTVERSION невозможно.
@@ -519,7 +519,7 @@
|gawk
|(пусто)
|2.15.6
-|
+|
|Японская языковая версия
|psutils-1.13
@@ -527,7 +527,7 @@
|psutils
|-letter
|1.13
-|
+|
|Размер бумаги жёстко задан во время сборки пакета
|pkfonts
@@ -535,7 +535,7 @@
|pkfonts
|300
|1.0
-|
+|
|Пакет для шрифтов с разрешением 300dpi
|===
@@ -575,47 +575,47 @@
|[.filename]#accessibility#
|Порты для помощи пользователям с ограниченными возможностями.
-|
+|
|[.filename]#afterstep#`*`
|Порты для поддержки оконного менеджера http://www.afterstep.org/[AfterStep].
-|
+|
|[.filename]#arabic#
|Поддержка арабского языка.
-|
+|
|[.filename]#archivers#
|Инструменты для архивирования.
-|
+|
|[.filename]#astro#
|Астрономические порты.
-|
+|
|[.filename]#audio#
|Поддержка звука.
-|
+|
|[.filename]#benchmarks#
|Утилиты для тестирования производительности.
-|
+|
|[.filename]#biology#
|Программное обеспечение, связанное с биологией.
-|
+|
|[.filename]#budgie#`*`
|Программное обеспечение, связанное со средой рабочего стола Budgie.
-|
+|
|[.filename]#cad#
|Компьютерные средства автоматизированного проектирования.
-|
+|
|[.filename]#chinese#
|Поддержка китайского языка.
-|
+|
|[.filename]#comms#
|Программное обеспечение для связи.
@@ -623,15 +623,15 @@
|[.filename]#converters#
|Преобразователи символьных кодировок.
-|
+|
|[.filename]#databases#
|Базы данных.
-|
+|
|[.filename]#deskutils#
|Вещи, которые раньше находились на рабочем столе до изобретения компьютеров.
-|
+|
|[.filename]#devel#
|Средства разработки.
@@ -639,11 +639,11 @@
|[.filename]#dns#
|Программное обеспечение, связанное с DNS.
-|
+|
|[.filename]#docs#`*`
|Мета-порты для документации FreeBSD.
-|
+|
|[.filename]#editors#
|Общие редакторы.
@@ -655,7 +655,7 @@
|[.filename]#elisp#`*`
|Порты Emacs-lisp.
-|
+|
|[.filename]#emulators#
|Эмуляторы других операционных систем.
@@ -663,19 +663,19 @@
|[.filename]#enlightenment#`*`
|Порты, связанные с оконным менеджером Enlightenment.
-|
+|
|[.filename]#filesystems#
|Файловые системы и связанные утилиты.
-|
+|
|[.filename]#finance#
|Монетарные, финансовые и связанные с ними приложения.
-|
+|
|[.filename]#french#
|Поддержка французского языка.
-|
+|
|[.filename]#ftp#
|Клиентские и серверные утилиты FTP.
@@ -683,51 +683,51 @@
|[.filename]#games#
|Игры.
-|
+|
|[.filename]#география#`*`
|Программное обеспечение, связанное с географией.
-|
+|
|[.filename]#german#
|Поддержка немецкого языка.
-|
+|
|[.filename]#gnome#`*`
|Порты из проекта https://www.gnome.org/[GNOME].
-|
+|
|[.filename]#gnustep#`*`
|Программное обеспечение, связанное со средой рабочего стола GNUstep.
-|
+|
|[.filename]#graphics#
|Графические утилиты.
-|
+|
|[.filename]#hamradio#`*`
|Программное обеспечение для радиолюбителей.
-|
+|
|[.filename]#haskell#`*`
|Программное обеспечение, связанное с языком Haskell.
-|
+|
|[.filename]#hebrew#
|Поддержка иврита.
-|
+|
|[.filename]#hungarian#
|Венгерская языковая поддержка.
-|
+|
|[.filename]#irc#
|Утилиты Internet Relay Chat.
-|
+|
|[.filename]#japanese#
|Поддержка японского языка.
-|
+|
|[.filename]#java#
|Программное обеспечение, связанное с языком Java(TM).
@@ -735,55 +735,55 @@
|[.filename]#kde#`*`
|Порты проекта https://www.kde.org/[KDE] (общие).
-|
+|
|[.filename]#kde-приложения#`*`
|Приложения от проекта https://www.kde.org/[KDE].
-|
+|
|[.filename]#kde-frameworks#`*`
|Дополнительные библиотеки от проекта https://www.kde.org/[KDE] для программирования с использованием Qt.
-|
+|
|[.filename]#kde-plasma#`*`
|Рабочий стол от проекта https://www.kde.org/[KDE].
-|
+|
|[.filename]#kld#`*`
|Загружаемые модули ядра.
-|
+|
|[.filename]#korean#
|Поддержка корейского языка.
-|
+|
|[.filename]#lang#
|Языки программирования.
-|
+|
|[.filename]#linux#`*`
|Приложения и вспомогательные утилиты Linux.
-|
+|
|[.filename]#lisp#`*`
|Программное обеспечение, связанное с языком Lisp.
-|
+|
|[.filename]#mail#
|Почтовое программное обеспечение.
-|
+|
|[.filename]#mate#`*`
|Порты, связанные с окружением рабочего стола MATE, форком GNOME 2.
-|
+|
|[.filename]#math#
|Численные расчеты и другие математические утилиты.
-|
+|
|[.filename]#mbone#`*`
|Приложения MBone.
-|
+|
|[.filename]#misc#
|Различные утилиты
@@ -791,59 +791,59 @@
|[.filename]#multimedia#
|Мультимедийное программное обеспечение.
-|
+|
|[.filename]#net#
|Различное сетевое программное обеспечение.
-|
+|
|[.filename]#net-im#
|Программное обеспечение для обмена мгновенными сообщениями.
-|
+|
|[.filename]#net-mgmt#
|Программное обеспечение для управления сетями.
-|
+|
|[.filename]#net-p2p#
|Одноранговые сетевые приложения.
-|
+|
|[.filename]#сеть-vpn#`*`
|Виртуальные частные сети.
-|
+|
|[.filename]#news#
|Программное обеспечение для USENET-новостей.
-|
+|
|[.filename]#parallel#`*`
|Приложения, работающие с параллелизмом в вычислениях.
-|
+|
|[.filename]#pear#`*`
|Порты, связанные с PHP-фреймворком Pear.
-|
+|
|[.filename]#perl5#`*`
|Порты, требующие Perl версии 5 для работы.
-|
+|
|[.filename]#plan9#`*`
|Различные программы с https://9p.io/wiki/plan9/Download/index.html[Plan9].
-|
+|
|[.filename]#polish#
|Поддержка польского языка.
-|
+|
|[.filename]#ports-mgmt#
|Порты для управления, установки и разработки портов и пакетов FreeBSD.
-|
+|
|[.filename]#portuguese#
|Поддержка португальского языка.
-|
+|
|[.filename]#print#
|Программное обеспечение для печати.
@@ -851,47 +851,47 @@
|[.filename]#python#`*`
|Программное обеспечение, связанное с языком https://www.python.org/[Python].
-|
+|
|[.filename]#ruby#`*`
|Программное обеспечение, связанное с языком https://www.ruby-lang.org/[Ruby].
-|
+|
|[.filename]#rubygems#`*`
|Порты пакетов https://www.rubygems.org/[RubyGems].
-|
+|
|[.filename]#russian#
|Поддержка русского языка.
-|
+|
|[.filename]#scheme#`*`
|Программное обеспечение, связанное с языком Scheme.
-|
+|
|[.filename]#science#
|Научные порты, которые не входят в другие категории, такие как [.filename]#astro#, [.filename]#biology# и [.filename]#math#.
-|
+|
|[.filename]#security#
|Средства обеспечения безопасности.
-|
+|
|[.filename]#shells#
|Командные оболочки.
-|
+|
|[.filename]#spanish#`*`
|Поддержка испанского языка.
-|
+|
|[.filename]#sysutils#
|Системные утилиты.
-|
+|
|[.filename]#tcl#`*`
|Порты, использующие Tcl для запуска.
-|
+|
|[.filename]#textproc#
|Средства обработки текста.
@@ -899,23 +899,23 @@
|[.filename]#tk#`*`
|Порты, использующие Tk для работы.
-|
+|
|[.filename]#ukrainian#
|Поддержка украинского языка.
-|
+|
|[.filename]#vietnamese#
|Поддержка вьетнамского языка.
-|
+|
|[.filename]#wayland#`*`
|Порты для поддержки сервера дисплея Wayland.
-|
+|
|[.filename]#windowmaker#`*`
|Порты для поддержки оконного менеджера Window Maker.
-|
+|
|[.filename]#www#
|Программное обеспечение, связанное с Всемирной паутиной.
@@ -927,43 +927,43 @@
|[.filename]#x11-clocks#
|Часы X11.
-|
+|
|[.filename]#x11-drivers#
|Драйверы X11.
-|
+|
|[.filename]#x11-fm#
|Менеджеры файлов X11.
-|
+|
|[.filename]#x11-fonts#
|Шрифты и утилиты для работы со шрифтами в X11.
-|
+|
|[.filename]#x11-servers#
|Серверы X11.
-|
+|
|[.filename]#x11-themes#
|Темы X11.
-|
+|
|[.filename]#x11-toolkits#
|Инструментарии X11.
-|
+|
|[.filename]#x11-wm#
|Оконные менеджеры X11.
-|
+|
|[.filename]#xfce#`*`
|Порты, связанные с окружением рабочего стола https://www.xfce.org/[Xfce].
-|
+|
|[.filename]#zope#`*`
|https://www.zope.org/[Zope] поддержка.
-|
+|
|===
[[choosing-categories]]
@@ -1381,7 +1381,7 @@
|`GH_TUPLE`
|`GH_TUPLE` позволяет объединить `GH_ACCOUNT`, `GH_PROJECT`, `GH_TAGNAME` и `GH_SUBDIR` в одну переменную. Формат следующий: _account_`:`_project_`:`_tagname_`:`_group_`/`_subdir_. Часть `/`_subdir_ является необязательной. Это полезно, когда требуется получить несколько проектов с GitHub.
-|
+|
|===
[IMPORTANT]
@@ -1428,9 +1428,9 @@
Он автоматически получит `MASTER_SITES` со значением `GH` и `WRKSRC` со значением `${WRKDIR}/pkg-6dbb17b`.
[TIP]
-****
+====
`20140411` — это дата коммита, указанного в `GH_TAGNAME`, а не дата редактирования файла [.filename]#Makefile# или дата создания коммита.
-****
+====
====
@@ -1522,7 +1522,7 @@
....
[NOTE]
-****
+=====
Если запрошенный коммит совпадает с тегом, по умолчанию отображается более короткое описание. Полная версия эквивалентна:
[source, shell]
@@ -1534,7 +1534,7 @@
v0.7.3-0-gc66c71d
....
-****
+=====
====
@@ -1695,9 +1695,9 @@
Это также можно найти на GitHub. Каждый подкаталог, который является подмодулем, отображается как `_каталог @ хэш_`, например, `mongoose @ 2140e59`.
[NOTE]
-****
+=====
Хотя получение информации из GitHub кажется более простым, данные, полученные с помощью `git submodule status`, будут более информативными. Например, здесь хеш коммита ``lib/wxsqlite3`` `fb66eb2` соответствует `v3.4.0`. Оба варианта можно использовать взаимозаменяемо, но если доступен тег, предпочтительнее использовать его.
-****
+=====
Теперь, когда вся необходимая информация собрана, можно написать [.filename]#Makefile# (показаны только строки, связанные с GitHub):
@@ -1754,7 +1754,7 @@
|`GL_TUPLE`
|`GL_TUPLE` позволяет объединить `GL_SITE`, `GL_ACCOUNT`, `GL_PROJECT`, `GL_COMMIT` и `GL_SUBDIR` в одну переменную. Формат записи: _сайт_`:`_учётная запись_`:`_проект_`:`_коммит_`:`_группа_`/`_подкаталог_. Части _сайт_`:` и `/`_подкаталог_ являются необязательными. Это полезно, когда требуется загрузить данные из нескольких проектов GitLab.
-|
+|
|===
[[makefile-master_sites-gitlab-ex1]]
@@ -2462,152 +2462,152 @@
|`CC-BY-1.0`
|Creative Commons с указанием авторства 1.0
-|
+|
|(по умолчанию)
|`CC-BY-2.0`
|Creative Commons с указанием авторства 2.0
-|
+|
|(по умолчанию)
|`CC-BY-2.5`
|Creative Commons с указанием авторства 2.5
-|
+|
|(по умолчанию)
|`CC-BY-3.0`
|Creative Commons с указанием авторства 3.0
-|
+|
|(по умолчанию)
|`CC-BY-4.0`
|Creative Commons с указанием авторства 4.0
-|
+|
|(по умолчанию)
|`CC-BY-NC-1.0`
|Creative Commons с указанием авторства – некоммерческая 1.0
-|
+|
|`dist-mirror``pkg-mirror``auto-accept`
|`CC-BY-NC-2.0`
|Creative Commons с указанием авторства – некоммерческая 2.0
-|
+|
|`dist-mirror``pkg-mirror``auto-accept`
|`CC-BY-NC-2.5`
|Creative Commons с указанием авторства – некоммерческая 2.5
-|
+|
|`dist-mirror``pkg-mirror``auto-accept`
|`CC-BY-NC-3.0`
|Creative Commons с указанием авторства – некоммерческая 3.0
-|
+|
|`dist-mirror``pkg-mirror``auto-accept`
|`CC-BY-NC-4.0`
|Creative Commons с указанием авторства – некоммерческая 4.0
-|
+|
|`dist-mirror``pkg-mirror``auto-accept`
|`CC-BY-NC-ND-1.0`
|Creative Commons с указанием авторства – некоммерческая – без производных 1.0
-|
+|
|`dist-mirror``pkg-mirror``auto-accept`
|`CC-BY-NC-ND-2.0`
|Creative Commons с указанием авторства – некоммерческая – без производных 2.0
-|
+|
|`dist-mirror``pkg-mirror``auto-accept`
|`CC-BY-NC-ND-2.5`
|Creative Commons с указанием авторства – некоммерческая – без производных 2.5
-|
+|
|`dist-mirror``pkg-mirror``auto-accept`
|`CC-BY-NC-ND-3.0`
|Creative Commons с указанием авторства – некоммерческая – без производных 3.0
-|
+|
|`dist-mirror``pkg-mirror``auto-accept`
|`CC-BY-NC-ND-4.0`
|Creative Commons с указанием авторства – некоммерческая – без производных 4.0
-|
+|
|`dist-mirror``pkg-mirror``auto-accept`
|`CC-BY-NC-SA-1.0`
|Creative Commons с указанием авторства – некоммерческая – на тех же условиях 1.0
-|
+|
|`dist-mirror``pkg-mirror``auto-accept`
|`CC-BY-NC-SA-2.0`
|Creative Commons с указанием авторства – некоммерческая – на тех же условиях 2.0
-|
+|
|`dist-mirror``pkg-mirror``auto-accept`
|`CC-BY-NC-SA-2.5`
|Creative Commons с указанием авторства – некоммерческая – на тех же условиях 2.5
-|
+|
|`dist-mirror``pkg-mirror``auto-accept`
|`CC-BY-NC-SA-3.0`
|Creative Commons с указанием авторства – некоммерческая – на тех же условиях 3.0
-|
+|
|`dist-mirror``pkg-mirror``auto-accept`
|`CC-BY-NC-SA-4.0`
|Creative Commons с указанием авторства – некоммерческая – на тех же условиях 4.0
-|
+|
|`dist-mirror``pkg-mirror``auto-accept`
|`CC-BY-ND-1.0`
|Creative Commons с указанием авторства – без производных 1.0
-|
+|
|(по умолчанию)
|`CC-BY-ND-2.0`
|Creative Commons с указанием авторства – без производных 2.0
-|
+|
|(по умолчанию)
|`CC-BY-ND-2.5`
|Creative Commons с указанием авторства – без производных 2.5
-|
+|
|(по умолчанию)
|`CC-BY-ND-3.0`
|Creative Commons с указанием авторства – без производных 3.0
-|
+|
|(по умолчанию)
|`CC-BY-ND-4.0`
|Creative Commons с указанием авторства – без производных 4.0
-|
+|
|(по умолчанию)
|`CC-BY-SA-1.0`
|Creative Commons с указанием авторства – на тех же условиях 1.0
-|
+|
|(по умолчанию)
|`CC-BY-SA-2.0`
|Creative Commons с указанием авторства – на тех же условиях 2.0
-|
+|
|(по умолчанию)
|`CC-BY-SA-2.5`
|Creative Commons с указанием авторства – на тех же условиях 2.5
-|
+|
|(по умолчанию)
|`CC-BY-SA-3.0`
|Creative Commons с указанием авторства – на тех же условиях 3.0
-|
+|
|(по умолчанию)
|`CC-BY-SA-4.0`
|Creative Commons с указанием авторства – на тех же условиях 4.0
-|
+|
|(по умолчанию)
|`CC0-1.0`
@@ -2782,7 +2782,7 @@
|`NONE`
|Лицензия не указана
-|
+|
|`none`
|`OFL10`
@@ -3340,7 +3340,7 @@
| Значение
|`USE_GCC`
-a|
+a|
Порт требует GCC (`gcc` или `{g-plus-plus}`) для сборки.
Некоторые порты нуждаются в определённой, старой версии GCC, другие требуют современных, актуальных версий.
diff --git a/documentation/content/ru/books/porters-handbook/pkg-files/_index.adoc b/documentation/content/ru/books/porters-handbook/pkg-files/_index.adoc
--- a/documentation/content/ru/books/porters-handbook/pkg-files/_index.adoc
+++ b/documentation/content/ru/books/porters-handbook/pkg-files/_index.adoc
@@ -206,9 +206,9 @@
....
[IMPORTANT]
-****
+=====
При отображении сообщения во время обновления важно ограничить случаи, когда оно показывается пользователю. Чаще всего это делается с помощью `maximum_version`, чтобы ограничить его использование обновлениями до определённой версии, когда требуется выполнить конкретное действие.
-****
+=====
====
diff --git a/documentation/content/ru/books/porters-handbook/quick-porting/_index.adoc b/documentation/content/ru/books/porters-handbook/quick-porting/_index.adoc
--- a/documentation/content/ru/books/porters-handbook/quick-porting/_index.adoc
+++ b/documentation/content/ru/books/porters-handbook/quick-porting/_index.adoc
@@ -253,9 +253,9 @@
Патч, созданный с помощью `git format-patch`, будет содержать идентификатор автора и адреса электронной почты, что упрощает применение разработчиками (с помощью `git am`) и правильное указание авторства.
[IMPORTANT]
-****
+====
Чтобы упростить применение патча для коммиттеров в их рабочей копии дерева портов, пожалуйста, создайте файл [.filename]#.diff# из корня вашего дерева портов.
-****
+====
====
diff --git a/documentation/content/ru/books/porters-handbook/testing/_index.adoc b/documentation/content/ru/books/porters-handbook/testing/_index.adoc
--- a/documentation/content/ru/books/porters-handbook/testing/_index.adoc
+++ b/documentation/content/ru/books/porters-handbook/testing/_index.adoc
@@ -490,9 +490,9 @@
DEFAULT_VERSIONS+= perl=5.20
....
[NOTE]
-****
+=====
Обратите внимание на использование `+=`, чтобы содержимое переменной не было перезаписано, если она уже установлена в стандартном [.filename]#make.conf#.
-****
+=====
====
diff --git a/documentation/content/zh-tw/books/developers-handbook/secure/_index.adoc b/documentation/content/zh-tw/books/developers-handbook/secure/_index.adoc
--- a/documentation/content/zh-tw/books/developers-handbook/secure/_index.adoc
+++ b/documentation/content/zh-tw/books/developers-handbook/secure/_index.adoc
@@ -1,6 +1,6 @@
---
title: 章 3. Secure Programming
-authors:
+authors:
- author: Murray Stokely
prev: books/developers-handbook/tools
next: books/developers-handbook/l10n
@@ -139,7 +139,7 @@
Let us examine what the memory image of this process would look like if we were to input 160 spaces into our little program before hitting return.
-[XXX figure here!]
+[ XXX figure here! ]
Obviously more malicious input can be devised to execute actual compiled instructions (such as exec(/bin/sh)).
diff --git a/documentation/content/zh-tw/books/porters-handbook/makefiles/_index.adoc b/documentation/content/zh-tw/books/porters-handbook/makefiles/_index.adoc
--- a/documentation/content/zh-tw/books/porters-handbook/makefiles/_index.adoc
+++ b/documentation/content/zh-tw/books/porters-handbook/makefiles/_index.adoc
@@ -133,10 +133,10 @@
<.> `1.2` is before `1.2p1` as `2p1`, think "2, patch level 1" which is a version after any `2.X` but before `3`.
[NOTE]
-****
+=====
In here, the `a`, `b`, and `p` are used as if meaning "alpha", "beta" or "pre-release" and "patch level",
but they are only letters and are sorted alphabetically, so any letter can be used, and they will be sorted appropriately.
-****
+=====
====
@@ -1124,7 +1124,7 @@
....
% pkg version -t 9.9.9 9.9.9.p1
> <.>
-% pkg version -t 9.9.9 9.9.9p1
+% pkg version -t 9.9.9 9.9.9p1
< <.>
....
@@ -1136,11 +1136,11 @@
[.programlisting]
....
PORTNAME= bind
-PORTVERSION= ${ISCVERSION:S/-P/P/:S/b/.b/:S/a/.a/:S/rc/.rc/}
+PORTVERSION= ${ISCVERSION:S/-P/P/:S/b/.b/:S/a/.a/:S/rc/.rc/}
CATEGORIES= dns net
-MASTER_SITES= ISC/bind9/${ISCVERSION}
+MASTER_SITES= ISC/bind9/${ISCVERSION}
PKGNAMESUFFIX= 99
-DISTNAME= ${PORTNAME}-${ISCVERSION}
+DISTNAME= ${PORTNAME}-${ISCVERSION}
MAINTAINER= mat@FreeBSD.org
COMMENT= BIND DNS suite with updated DNSSEC and DNS64
@@ -1513,9 +1513,9 @@
It will automatically have `MASTER_SITES` set to `GH` and `WRKSRC` to `${WRKDIR}/pkg-6dbb17b`.
[TIP]
-****
+====
`20140411` is the date of the commit referenced in `GH_TAGNAME`, not the date the [.filename]#Makefile# is edited, or the date the commit is made.
-****
+====
====
@@ -1611,7 +1611,7 @@
....
[NOTE]
-****
+=====
If the requested commit is the same as a tag, a shorter description is shown by default.
The longer version is equivalent:
@@ -1624,7 +1624,7 @@
v0.7.3-0-gc66c71d
....
-****
+=====
====
@@ -1813,11 +1813,11 @@
Each subdirectory that is a submodule is shown as `_directory @ hash_`, for example, `mongoose @ 2140e59`.
[NOTE]
-****
+=====
While getting the information from GitHub seems more straightforward, the information found using `git submodule status` will provide more meaningful information.
For example, here, ``lib/wxsqlite3``'s commit hash `fb66eb2` correspond to `v3.4.0`.
Both can be used interchangeably, but when a tag is available, use it.
-****
+=====
Now that all the required information has been gathered, the [.filename]#Makefile# can be written (only GitHub-related lines are shown):
diff --git a/documentation/content/zh-tw/books/porters-handbook/pkg-files/_index.adoc b/documentation/content/zh-tw/books/porters-handbook/pkg-files/_index.adoc
--- a/documentation/content/zh-tw/books/porters-handbook/pkg-files/_index.adoc
+++ b/documentation/content/zh-tw/books/porters-handbook/pkg-files/_index.adoc
@@ -215,10 +215,10 @@
....
[IMPORTANT]
-****
+=====
When displaying a message on upgrade, it is important to limit when it is being shown to the user.
Most of the time it is by using `maximum_version` to limit its usage to upgrades from before a certain version when something specific needs to be done.
-****
+=====
====
diff --git a/documentation/content/zh-tw/books/porters-handbook/quick-porting/_index.adoc b/documentation/content/zh-tw/books/porters-handbook/quick-porting/_index.adoc
--- a/documentation/content/zh-tw/books/porters-handbook/quick-porting/_index.adoc
+++ b/documentation/content/zh-tw/books/porters-handbook/quick-porting/_index.adoc
@@ -134,7 +134,7 @@
[NOTE]
====
-建議清單內的檔名，依照字母順序作排序，那麼下次要升級時， 會比較清楚、方便來更新這份清單。
+建議清單內的檔名，依照字母順序作排序，那麼下次要升級時， 會比較清楚、方便來更新這份清單。
====
[TIP]
@@ -259,9 +259,9 @@
[IMPORTANT]
-****
+====
為了讓開發者更容易在他們的 ports tree 使用此 patch ，請基於你的 ports tree 來產生 [.filename]#.diff# 。
-****
+====
====

File Metadata

Mime Type
text/plain
Expires
Sat, Jul 4, 6:39 AM (17 h, 53 m)
Storage Engine
blob
Storage Format
Raw Data
Storage Handle
34657123
Default Alt Text
D57999.diff (111 KB)

Event Timeline