From owner-svn-doc-head@freebsd.org Sun Aug 26 07:29:59 2018 Return-Path: Delivered-To: svn-doc-head@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4E079106BFA9; Sun, 26 Aug 2018 07:29:59 +0000 (UTC) (envelope-from eadler@FreeBSD.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mxrelay.nyi.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E88F6749D6; Sun, 26 Aug 2018 07:29:58 +0000 (UTC) (envelope-from eadler@FreeBSD.org) Received: from repo.freebsd.org (repo.freebsd.org [IPv6:2610:1c1:1:6068::e6a:0]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id C40213CCE; Sun, 26 Aug 2018 07:29:58 +0000 (UTC) (envelope-from eadler@FreeBSD.org) Received: from repo.freebsd.org ([127.0.1.37]) by repo.freebsd.org (8.15.2/8.15.2) with ESMTP id w7Q7Twjw067268; Sun, 26 Aug 2018 07:29:58 GMT (envelope-from eadler@FreeBSD.org) Received: (from eadler@localhost) by repo.freebsd.org (8.15.2/8.15.2/Submit) id w7Q7TwVN067267; Sun, 26 Aug 2018 07:29:58 GMT (envelope-from eadler@FreeBSD.org) Message-Id: <201808260729.w7Q7TwVN067267@repo.freebsd.org> X-Authentication-Warning: repo.freebsd.org: eadler set sender to eadler@FreeBSD.org using -f From: Eitan Adler Date: Sun, 26 Aug 2018 07:29:58 +0000 (UTC) To: doc-committers@freebsd.org, svn-doc-all@freebsd.org, svn-doc-head@freebsd.org Subject: svn commit: r52174 - head/en_US.ISO8859-1/htdocs/java X-SVN-Group: doc-head X-SVN-Commit-Author: eadler X-SVN-Commit-Paths: head/en_US.ISO8859-1/htdocs/java X-SVN-Commit-Revision: 52174 X-SVN-Commit-Repository: doc MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-BeenThere: svn-doc-head@freebsd.org X-Mailman-Version: 2.1.27 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, 26 Aug 2018 07:29:59 -0000 Author: eadler Date: Sun Aug 26 07:29:58 2018 New Revision: 52174 URL: https://svnweb.freebsd.org/changeset/doc/52174 Log: java: update link to Java home page As much as it pains me, the link should point to Oracle and not to Sun. Modified: head/en_US.ISO8859-1/htdocs/java/index.xml Modified: head/en_US.ISO8859-1/htdocs/java/index.xml ============================================================================== --- head/en_US.ISO8859-1/htdocs/java/index.xml Fri Aug 24 21:34:24 2018 (r52173) +++ head/en_US.ISO8859-1/htdocs/java/index.xml Sun Aug 26 07:29:58 2018 (r52174) @@ -13,7 +13,7 @@ - Jump to &java;

Getting Java

From owner-svn-doc-head@freebsd.org Sun Aug 26 14:08:20 2018 Return-Path: Delivered-To: svn-doc-head@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 5641010777F1; Sun, 26 Aug 2018 14:08:20 +0000 (UTC) (envelope-from bcr@FreeBSD.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mxrelay.nyi.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id EFFFF82254; Sun, 26 Aug 2018 14:08:19 +0000 (UTC) (envelope-from bcr@FreeBSD.org) Received: from repo.freebsd.org (repo.freebsd.org [IPv6:2610:1c1:1:6068::e6a:0]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id CB4F57EBF; Sun, 26 Aug 2018 14:08:19 +0000 (UTC) (envelope-from bcr@FreeBSD.org) Received: from repo.freebsd.org ([127.0.1.37]) by repo.freebsd.org (8.15.2/8.15.2) with ESMTP id w7QE8JRc071637; Sun, 26 Aug 2018 14:08:19 GMT (envelope-from bcr@FreeBSD.org) Received: (from bcr@localhost) by repo.freebsd.org (8.15.2/8.15.2/Submit) id w7QE8JFE071636; Sun, 26 Aug 2018 14:08:19 GMT (envelope-from bcr@FreeBSD.org) Message-Id: <201808261408.w7QE8JFE071636@repo.freebsd.org> X-Authentication-Warning: repo.freebsd.org: bcr set sender to bcr@FreeBSD.org using -f From: Benedict Reuschling Date: Sun, 26 Aug 2018 14:08:19 +0000 (UTC) To: doc-committers@freebsd.org, svn-doc-all@freebsd.org, svn-doc-head@freebsd.org Subject: svn commit: r52175 - head/en_US.ISO8859-1/books/developers-handbook/ipv6 X-SVN-Group: doc-head X-SVN-Commit-Author: bcr X-SVN-Commit-Paths: head/en_US.ISO8859-1/books/developers-handbook/ipv6 X-SVN-Commit-Revision: 52175 X-SVN-Commit-Repository: doc MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-BeenThere: svn-doc-head@freebsd.org X-Mailman-Version: 2.1.27 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, 26 Aug 2018 14:08:20 -0000 Author: bcr Date: Sun Aug 26 14:08:19 2018 New Revision: 52175 URL: https://svnweb.freebsd.org/changeset/doc/52175 Log: Fix errors reported by textproc/igor: - wrap long lines - add blank lines after tags - use tabs instead of spaces - use two spaces at sentence start - Capitalization in title tags (where appropriate) Modified: head/en_US.ISO8859-1/books/developers-handbook/ipv6/chapter.xml Modified: head/en_US.ISO8859-1/books/developers-handbook/ipv6/chapter.xml ============================================================================== --- head/en_US.ISO8859-1/books/developers-handbook/ipv6/chapter.xml Sun Aug 26 07:29:58 2018 (r52174) +++ head/en_US.ISO8859-1/books/developers-handbook/ipv6/chapter.xml Sun Aug 26 14:08:19 2018 (r52175) @@ -4,519 +4,567 @@ $FreeBSD$ --> -<chapter xmlns="http://docbook.org/ns/docbook" xmlns:xlink="http://www.w3.org/1999/xlink" version="5.0" xml:id="ipv6"> +<chapter xmlns="http://docbook.org/ns/docbook" + xmlns:xlink="http://www.w3.org/1999/xlink" version="5.0" + xml:id="ipv6"> <title>IPv6 Internals - IPv6/IPsec Implementation + + IPv6/IPsec Implementation + - YoshinobuInoueContributed by + + + Yoshinobu + Inoue + + Contributed by + - - + This section should explain IPv6 and IPsec related + implementation internals. These functionalities are derived + from KAME + project - This section should explain IPv6 and IPsec related implementation - internals. These functionalities are derived from KAME project - IPv6 - Conformance + Conformance - The IPv6 related functions conforms, or tries to conform to - the latest set of IPv6 specifications. For future reference we list - some of the relevant documents below (NOTE: this - is not a complete list - this is too hard to maintain...). + The IPv6 related functions conforms, or tries to conform + to the latest set of IPv6 specifications. For future + reference we list some of the relevant documents below + (NOTE: this is not a complete list - + this is too hard to maintain...). - For details please refer to specific chapter in the document, - RFCs, manual pages, or comments in the source code. + For details please refer to specific chapter in the + document, RFCs, manual pages, or comments in the source + code. - Conformance tests have been performed on the KAME STABLE kit - at TAHI project. Results can be viewed at - http://www.tahi.org/report/KAME/. - We also attended Univ. of New Hampshire IOL tests - (http://www.iol.unh.edu/) in the - past, with our past snapshots. + Conformance tests have been performed on the KAME STABLE + kit at TAHI project. Results can be viewed at http://www.tahi.org/report/KAME/. + We also attended University of New Hampshire IOL tests (http://www.iol.unh.edu/) + in the past, with our past snapshots. - - + + RFC1639: FTP Operation Over Big Address Records - (FOOBAR) + (FOOBAR) - RFC2428 is preferred over RFC1639. FTP clients will - first try RFC2428, then RFC1639 if failed. + RFC2428 is preferred over RFC1639. FTP clients + will first try RFC2428, then RFC1639 if + failed. - + - + RFC1886: DNS Extensions to support IPv6 - + RFC1933: Transition Mechanisms for IPv6 Hosts and - Routers + Routers - - IPv4 compatible address is not supported. + + IPv4 compatible address is not supported. - - automatic tunneling (described in 4.3 of this RFC) is not - supported. + + automatic tunneling (described in 4.3 of this + RFC) is not supported. - - &man.gif.4; interface implements IPv[46]-over-IPv[46] - tunnel in a generic way, and it covers "configured tunnel" - described in the spec. See 23.5.1.5 - in this document for details. + + &man.gif.4; interface implements + IPv[46]-over-IPv[46] tunnel in a generic way, and it + covers "configured tunnel" described in the spec. + See 23.5.1.5 in this + document for details. - + - - RFC1981: Path MTU Discovery for IPv6 - + + RFC1981: Path MTU Discovery for IPv6 + - - RFC2080: RIPng for IPv6 + + RFC2080: RIPng for IPv6 - usr.sbin/route6d support this. - + usr.sbin/route6d support this. + - + - - RFC2292: Advanced Sockets API for IPv6 + + RFC2292: Advanced Sockets API for IPv6 For supported library functions/kernel APIs, see - sys/netinet6/ADVAPI. + sys/netinet6/ADVAPI. - + - - RFC2362: Protocol Independent Multicast-Sparse - Mode (PIM-SM) + + RFC2362: Protocol Independent Multicast-Sparse Mode + (PIM-SM) RFC2362 defines packet formats for PIM-SM. - draft-ietf-pim-ipv6-01.txt is - written based on this. + draft-ietf-pim-ipv6-01.txt is + written based on this. - + - + RFC2373: IPv6 Addressing Architecture - supports node required addresses, and conforms to - the scope requirement. + supports node required addresses, and conforms + to the scope requirement. - + - + RFC2374: An IPv6 Aggregatable Global Unicast Address - Format + Format supports 64-bit length of Interface ID. - + - + RFC2375: IPv6 Multicast Address Assignments - Userland applications use the well-known addresses - assigned in the RFC. + Userland applications use the well-known + addresses assigned in the RFC. - + - + RFC2428: FTP Extensions for IPv6 and NATs - RFC2428 is preferred over RFC1639. FTP clients will - first try RFC2428, then RFC1639 if failed. + RFC2428 is preferred over RFC1639. FTP clients + will first try RFC2428, then RFC1639 if + failed. - + - + RFC2460: IPv6 specification - + - + RFC2461: Neighbor discovery for IPv6 - See 23.5.1.2 - in this document for details. + See 23.5.1.2 in + this document for details. - + - - RFC2462: IPv6 Stateless Address Autoconfiguration + + RFC2462: IPv6 Stateless Address + Autoconfiguration - See 23.5.1.4 in this - document for details. + See 23.5.1.4 in + this document for details. - + - + RFC2463: ICMPv6 for IPv6 specification - See 23.5.1.9 in this - document for details. + See 23.5.1.9 in + this document for details. - + - + RFC2464: Transmission of IPv6 Packets over Ethernet - Networks - + Networks + - - RFC2465: MIB for IPv6: Textual Conventions and General - Group + + RFC2465: MIB for IPv6: Textual Conventions and + General Group - Necessary statistics are gathered by the kernel. Actual - IPv6 MIB support is provided as a patchkit for ucd-snmp. + Necessary statistics are gathered by the kernel. + Actual IPv6 MIB support is provided as a patchkit + for ucd-snmp. - + - + RFC2466: MIB for IPv6: ICMPv6 group - Necessary statistics are gathered by the kernel. Actual - IPv6 MIB support is provided as patchkit for ucd-snmp. + Necessary statistics are gathered by the kernel. + Actual IPv6 MIB support is provided as patchkit for + ucd-snmp. - + - + RFC2467: Transmission of IPv6 Packets over FDDI - Networks - + Networks + - + RFC2497: Transmission of IPv6 packet over ARCnet - Networks - + Networks + - - RFC2553: Basic Socket Interface Extensions for IPv6 + + RFC2553: Basic Socket Interface Extensions for + IPv6 - IPv4 mapped address (3.7) and special behavior of IPv6 - wildcard bind socket (3.8) are supported. See 23.5.1.12 - in this document for details. + IPv4 mapped address (3.7) and special behavior + of IPv6 wildcard bind socket (3.8) are supported. + See 23.5.1.12 in + this document for details. - + - + RFC2675: IPv6 Jumbograms - See 23.5.1.7 in - this document for details. + See 23.5.1.7 + in this document for details. - + - - RFC2710: Multicast Listener Discovery for IPv6 - + + RFC2710: Multicast Listener Discovery for + IPv6 + - + RFC2711: IPv6 router alert option - + - - draft-ietf-ipngwg-router-renum-08: Router - renumbering for IPv6 - + + draft-ietf-ipngwg-router-renum-08: + Router renumbering for IPv6 + - + draft-ietf-ipngwg-icmp-namelookups-02: - IPv6 Name Lookups Through ICMP - + IPv6 Name Lookups Through ICMP + - + draft-ietf-ipngwg-icmp-name-lookups-03: - IPv6 Name Lookups Through ICMP - + IPv6 Name Lookups Through ICMP + - - draft-ietf-pim-ipv6-01.txt: - PIM for IPv6 + + draft-ietf-pim-ipv6-01.txt: PIM + for IPv6 - &man.pim6dd.8; implements dense mode. &man.pim6sd.8; - implements sparse mode. + &man.pim6dd.8; implements dense mode. + &man.pim6sd.8; implements sparse mode. - + - + draft-itojun-ipv6-tcp-to-anycast-00: - Disconnecting TCP connection toward IPv6 anycast address - + Disconnecting TCP connection toward IPv6 anycast + address + - - draft-yamamoto-wideipv6-comm-model-00 - + + draft-yamamoto-wideipv6-comm-model-00 - See 23.5.1.6 in this - document for details. + See 23.5.1.6 in + this document for details. - + - - draft-ietf-ipngwg-scopedaddr-format-00.txt - : An Extension of Format for IPv6 Scoped - Addresses - - + + draft-ietf-ipngwg-scopedaddr-format-00.txt: + An Extension of Format for IPv6 Scoped Addresses + + - Neighbor Discovery + Neighbor Discovery - Neighbor Discovery is fairly stable. Currently Address - Resolution, Duplicated Address Detection, and Neighbor Unreachability - Detection are supported. In the near future we will be adding Proxy - Neighbor Advertisement support in the kernel and Unsolicited Neighbor - Advertisement transmission command as admin tool. + Neighbor Discovery is fairly stable. Currently Address + Resolution, Duplicated Address Detection, and Neighbor + Unreachability Detection are supported. In the near future + we will be adding Proxy Neighbor Advertisement support in + the kernel and Unsolicited Neighbor Advertisement + transmission command as admin tool. - If DAD fails, the address will be marked "duplicated" and - message will be generated to syslog (and usually to console). The - "duplicated" mark can be checked with &man.ifconfig.8;. It is - administrators' responsibility to check for and recover from DAD - failures. The behavior should be improved in the near future. + If DAD fails, the address will be marked "duplicated" + and message will be generated to syslog (and usually to + console). The "duplicated" mark can be checked with + &man.ifconfig.8;. It is administrators' responsibility to + check for and recover from DAD failures. The behavior + should be improved in the near future. - Some of the network driver loops multicast packets back to itself, - even if instructed not to do so (especially in promiscuous mode). - In such cases DAD may fail, because DAD engine sees inbound NS packet - (actually from the node itself) and considers it as a sign of duplicate. - You may want to look at #if condition marked "heuristics" in - sys/netinet6/nd6_nbr.c:nd6_dad_timer() as workaround (note that the code - fragment in "heuristics" section is not spec conformant). + Some of the network driver loops multicast packets back + to itself, even if instructed not to do so (especially in + promiscuous mode). In such cases DAD may fail, because DAD + engine sees inbound NS packet (actually from the node + itself) and considers it as a sign of duplicate. You may + want to look at #if condition marked "heuristics" in + sys/netinet6/nd6_nbr.c:nd6_dad_timer() as workaround (note + that the code fragment in "heuristics" section is not spec + conformant). - Neighbor Discovery specification (RFC2461) does not talk about - neighbor cache handling in the following cases: + Neighbor Discovery specification (RFC2461) does not talk + about neighbor cache handling in the following cases: - + when there was no neighbor cache entry, node - received unsolicited RS/NS/NA/redirect packet without - link-layer address - - - neighbor cache handling on medium without link-layer - address (we need a neighbor cache entry for IsRouter bit) - + received unsolicited RS/NS/NA/redirect packet without + link-layer address + + + neighbor cache handling on medium without link-layer + address (we need a neighbor cache entry for IsRouter + bit) + - For first case, we implemented workaround based on discussions - on IETF ipngwg mailing list. For more details, see the comments in - the source code and email thread started from (IPng 7155), dated - Feb 6 1999. + For first case, we implemented workaround based on + discussions on IETF ipngwg mailing list. For more details, + see the comments in the source code and email thread started + from (IPng 7155), dated Feb 6 1999. - IPv6 on-link determination rule (RFC2461) is quite different - from assumptions in BSD network code. At this moment, no on-link - determination rule is supported where default router list is empty - (RFC2461, section 5.2, last sentence in 2nd paragraph - note that - the spec misuse the word "host" and "node" in several places in - the section). + IPv6 on-link determination rule (RFC2461) is quite + different from assumptions in BSD network code. At this + moment, no on-link determination rule is supported where + default router list is empty (RFC2461, section 5.2, last + sentence in 2nd paragraph - note that the spec misuse the + word "host" and "node" in several places in the + section). - To avoid possible DoS attacks and infinite loops, only 10 - options on ND packet is accepted now. Therefore, if you have 20 - prefix options attached to RA, only the first 10 prefixes will be - recognized. If this troubles you, please ask it on FREEBSD-CURRENT - mailing list and/or modify nd6_maxndopt in - sys/netinet6/nd6.c. If there are high demands - we may provide sysctl knob for the variable. + To avoid possible DoS attacks and infinite loops, only + 10 options on ND packet is accepted now. Therefore, if you + have 20 prefix options attached to RA, only the first 10 + prefixes will be recognized. If this troubles you, please + ask it on FREEBSD-CURRENT mailing list and/or modify + nd6_maxndopt in sys/netinet6/nd6.c. If + there are high demands we may provide sysctl knob for the + variable. - Scope Index + Scope Index - IPv6 uses scoped addresses. Therefore, it is very important to - specify scope index (interface index for link-local address, or - site index for site-local address) with an IPv6 address. Without - scope index, scoped IPv6 address is ambiguous to the kernel, and - kernel will not be able to determine the outbound interface for a - packet. + IPv6 uses scoped addresses. Therefore, it is very + important to specify scope index (interface index for + link-local address, or site index for site-local address) + with an IPv6 address. Without scope index, scoped IPv6 + address is ambiguous to the kernel, and kernel will not be + able to determine the outbound interface for a + packet. Ordinary userland applications should use advanced API - (RFC2292) to specify scope index, or interface index. For similar - purpose, sin6_scope_id member in sockaddr_in6 structure is defined - in RFC2553. However, the semantics for sin6_scope_id is rather vague. - If you care about portability of your application, we suggest you to - use advanced API rather than sin6_scope_id. + (RFC2292) to specify scope index, or interface index. For + similar purpose, sin6_scope_id member in sockaddr_in6 + structure is defined in RFC2553. However, the semantics for + sin6_scope_id is rather vague. If you care about + portability of your application, we suggest you to use + advanced API rather than sin6_scope_id. - In the kernel, an interface index for link-local scoped address is - embedded into 2nd 16bit-word (3rd and 4th byte) in IPv6 address. For - example, you may see something like: - + In the kernel, an interface index for link-local scoped + address is embedded into 2nd 16bit-word (3rd and 4th byte) + in IPv6 address. For example, you may see something + like: fe80:1::200:f8ff:fe01:6317 - in the routing table and interface address structure (struct - in6_ifaddr). The address above is a link-local unicast address - which belongs to a network interface whose interface identifier is 1. - The embedded index enables us to identify IPv6 link local - addresses over multiple interfaces effectively and with only a - little code change. + in the routing table and interface address structure + (struct in6_ifaddr). The address above is a link-local + unicast address which belongs to a network interface whose + interface identifier is 1. The embedded index enables us to + identify IPv6 link local addresses over multiple interfaces + effectively and with only a little code change. - Routing daemons and configuration programs, like &man.route6d.8; - and &man.ifconfig.8;, will need to manipulate the "embedded" scope - index. These programs use routing sockets and ioctls (like - SIOCGIFADDR_IN6) and the kernel API will return IPv6 addresses with - 2nd 16bit-word filled in. The APIs are for manipulating kernel - internal structure. Programs that use these APIs have to be prepared - about differences in kernels anyway. + Routing daemons and configuration programs, like + &man.route6d.8; and &man.ifconfig.8;, will need to + manipulate the "embedded" scope index. These programs use + routing sockets and ioctls (like SIOCGIFADDR_IN6) and the + kernel API will return IPv6 addresses with 2nd 16bit-word + filled in. The APIs are for manipulating kernel internal + structure. Programs that use these APIs have to be prepared + about differences in kernels anyway. - When you specify scoped address to the command line, NEVER write - the embedded form (such as ff02:1::1 or fe80:2::fedc). This is not - supposed to work. Always use standard form, like ff02::1 or - fe80::fedc, with command line option for specifying interface (like - ping6 -I ne0 ff02::1). In general, if a command - does not have command line option to specify outgoing interface, that - command is not ready to accept scoped address. This may seem to be - opposite from IPv6's premise to support "dentist office" situation. - We believe that specifications need some improvements for this. + When you specify scoped address to the command line, + NEVER write the embedded form (such as ff02:1::1 or + fe80:2::fedc). This is not supposed to work. Always use + standard form, like ff02::1 or fe80::fedc, with command line + option for specifying interface (like ping6 -I ne0 + ff02::1). In general, if a command does not + have command line option to specify outgoing interface, that + command is not ready to accept scoped address. This may + seem to be opposite from IPv6's premise to support "dentist + office" situation. We believe that specifications need some + improvements for this. - Some of the userland tools support extended numeric IPv6 syntax, - as documented in - draft-ietf-ipngwg-scopedaddr-format-00.txt. You - can specify outgoing link, by using name of the outgoing interface - like "fe80::1%ne0". This way you will be able to specify link-local - scoped address without much trouble. + Some of the userland tools support extended numeric IPv6 + syntax, as documented in + draft-ietf-ipngwg-scopedaddr-format-00.txt. + You can specify outgoing link, by using name of the outgoing + interface like "fe80::1%ne0". This way you will be able to + specify link-local scoped address without much + trouble. - To use this extension in your program, you will need to use - &man.getaddrinfo.3;, and &man.getnameinfo.3; with NI_WITHSCOPEID. - The implementation currently assumes 1-to-1 relationship between a - link and an interface, which is stronger than what specs say. + To use this extension in your program, you will need to + use &man.getaddrinfo.3;, and &man.getnameinfo.3; with + NI_WITHSCOPEID. The implementation currently assumes 1-to-1 + relationship between a link and an interface, which is + stronger than what specs say. Plug and Play - Most of the IPv6 stateless address autoconfiguration is implemented - in the kernel. Neighbor Discovery functions are implemented in the - kernel as a whole. Router Advertisement (RA) input for hosts is - implemented in the kernel. Router Solicitation (RS) output for - endhosts, RS input for routers, and RA output for routers are - implemented in the userland. + Most of the IPv6 stateless address autoconfiguration is + implemented in the kernel. Neighbor Discovery functions are + implemented in the kernel as a whole. Router Advertisement + (RA) input for hosts is implemented in the kernel. Router + Solicitation (RS) output for endhosts, RS input for routers, + and RA output for routers are implemented in the + userland. - - Assignment of link-local, and special addresses + + Assignment of link-local, and special + addresses - IPv6 link-local address is generated from IEEE802 address - (Ethernet MAC address). Each of interface is assigned an IPv6 - link-local address automatically, when the interface becomes up - (IFF_UP). Also, direct route for the link-local address is added - to routing table. + IPv6 link-local address is generated from IEEE802 + address (Ethernet MAC address). Each of interface is + assigned an IPv6 link-local address automatically, when + the interface becomes up (IFF_UP). Also, direct route for + the link-local address is added to routing table. Here is an output of netstat command: -Internet6: + Internet6: Destination Gateway Flags Netif Expire fe80:1::%ed0/64 link#1 UC ed0 fe80:2::%ep0/64 link#2 UC ep0 - Interfaces that has no IEEE802 address (pseudo interfaces - like tunnel interfaces, or ppp interfaces) will borrow IEEE802 - address from other interfaces, such as Ethernet interfaces, - whenever possible. If there is no IEEE802 hardware attached, - a last resort pseudo-random value, MD5(hostname), will - be used as source of link-local address. If it is not suitable - for your usage, you will need to configure the link-local address - manually. + Interfaces that has no IEEE802 address (pseudo + interfaces like tunnel interfaces, or ppp interfaces) will + borrow IEEE802 address from other interfaces, such as + Ethernet interfaces, whenever possible. If there is no + IEEE802 hardware attached, a last resort pseudo-random + value, MD5(hostname), will be used as source of link-local + address. If it is not suitable for your usage, you will + need to configure the link-local address manually. - If an interface is not capable of handling IPv6 (such as - lack of multicast support), link-local address will not be - assigned to that interface. See section 2 for details. + If an interface is not capable of handling IPv6 (such + as lack of multicast support), link-local address will not + be assigned to that interface. See section 2 for + details. - Each interface joins the solicited multicast address and the - link-local all-nodes multicast addresses (e.g. fe80::1:ff01:6317 - and ff02::1, respectively, on the link the interface is attached). - In addition to a link-local address, the loopback address (::1) - will be assigned to the loopback interface. Also, ::1/128 and - ff01::/32 are automatically added to routing table, and loopback - interface joins node-local multicast group ff01::1. - + Each interface joins the solicited multicast address + and the link-local all-nodes multicast addresses (e.g., + fe80::1:ff01:6317 and ff02::1, respectively, on the link + the interface is attached). In addition to a link-local + address, the loopback address (::1) will be assigned to + the loopback interface. Also, ::1/128 and ff01::/32 are + automatically added to routing table, and loopback + interface joins node-local multicast group ff01::1. + - - Stateless address autoconfiguration on hosts + + Stateless address autoconfiguration on Hosts - In IPv6 specification, nodes are separated into two categories: - routers and hosts. Routers - forward packets addressed to others, hosts does not forward the - packets. net.inet6.ip6.forwarding defines whether this node is - router or host (router if it is 1, host if it is 0). + In IPv6 specification, nodes are separated into two + categories: routers and + hosts. Routers forward packets + addressed to others, hosts does not forward the packets. + net.inet6.ip6.forwarding defines whether this node is + router or host (router if it is 1, host if it is + 0). - When a host hears Router Advertisement from the router, a host - may autoconfigure itself by stateless address autoconfiguration. - This behavior can be controlled by net.inet6.ip6.accept_rtadv (host - autoconfigures itself if it is set to 1). By autoconfiguration, - network address prefix for the receiving interface (usually global - address prefix) is added. Default route is also configured. - Routers periodically generate Router Advertisement packets. To - request an adjacent router to generate RA packet, a host can - transmit Router Solicitation. To generate a RS packet at any time, - use the rtsol command. &man.rtsold.8; daemon is - also available. &man.rtsold.8; generates Router Solicitation whenever - necessary, and it works great for nomadic usage (notebooks/laptops). - If one wishes to ignore Router Advertisements, use sysctl to set - net.inet6.ip6.accept_rtadv to 0. + When a host hears Router Advertisement from the + router, a host may autoconfigure itself by stateless + address autoconfiguration. This behavior can be + controlled by net.inet6.ip6.accept_rtadv (host + autoconfigures itself if it is set to 1). By + autoconfiguration, network address prefix for the + receiving interface (usually global address prefix) is + added. Default route is also configured. Routers + periodically generate Router Advertisement packets. To + request an adjacent router to generate RA packet, a host + can transmit Router Solicitation. To generate a RS packet + at any time, use the rtsol command. + &man.rtsold.8; daemon is also available. &man.rtsold.8; + generates Router Solicitation whenever necessary, and it + works great for nomadic usage (notebooks/laptops). If one + wishes to ignore Router Advertisements, use sysctl to set + net.inet6.ip6.accept_rtadv to 0. - To generate Router Advertisement from a router, use the - &man.rtadvd.8; daemon. + To generate Router Advertisement from a router, use + the &man.rtadvd.8; daemon. - Note that, IPv6 specification assumes the following items, and - nonconforming cases are left unspecified: + Note that, IPv6 specification assumes the following + items, and nonconforming cases are left + unspecified: - Only hosts will listen to router advertisements + Only hosts will listen to router + advertisements - Hosts have single network interface (except loopback) + Hosts have single network interface (except + loopback) - Therefore, this is unwise to enable net.inet6.ip6.accept_rtadv - on routers, or multi-interface host. A misconfigured node can - behave strange (nonconforming configuration allowed for those who - would like to do some experiments). + Therefore, this is unwise to enable + net.inet6.ip6.accept_rtadv on routers, or multi-interface + host. A misconfigured node can behave strange + (nonconforming configuration allowed for those who would + like to do some experiments). To summarize the sysctl knob: - accept_rtadv forwarding role of the node + accept_rtadv forwarding role of the node --- --- --- 0 0 host (to be manually configured) 0 1 router @@ -529,23 +577,25 @@ fe80:2::%ep0/64 link#2 (out-of-scope of spec) RFC2462 has validation rule against incoming RA prefix - information option, in 5.5.3 (e). This is to protect hosts from - malicious (or misconfigured) routers that advertise very short - prefix lifetime. There was an update from Jim Bound to ipngwg - mailing list (look for "(ipng 6712)" in the archive) and it is - implemented Jim's update. + information option, in 5.5.3 (e). This is to protect + hosts from malicious (or misconfigured) routers that + advertise very short prefix lifetime. There was an update + from Jim Bound to ipngwg mailing list (look for "(ipng + 6712)" in the archive) and it is implemented Jim's + update. - See 23.5.1.2 in - the document for relationship between DAD and - autoconfiguration. - + See 23.5.1.2 + in the document for relationship between DAD and + autoconfiguration. + - Generic tunnel interface + Generic Tunnel Interface - GIF (Generic InterFace) is a pseudo interface for configured - tunnel. Details are described in &man.gif.4;. Currently + GIF (Generic InterFace) is a pseudo interface for + configured tunnel. Details are described in &man.gif.4;. + Currently @@ -562,267 +612,286 @@ fe80:2::%ep0/64 link#2 - are available. Use &man.gifconfig.8; to assign physical (outer) - source and destination address to gif interfaces. Configuration that - uses same address family for inner and outer IP header (v4 in v4, or - v6 in v6) is dangerous. It is very easy to configure interfaces and - routing tables to perform infinite level of tunneling. - Please be warned. + are available. Use &man.gifconfig.8; to assign physical + (outer) source and destination address to gif interfaces. + Configuration that uses same address family for inner and + outer IP header (v4 in v4, or v6 in v6) is dangerous. It is + very easy to configure interfaces and routing tables to + perform infinite level of tunneling. Please be + warned. - gif can be configured to be ECN-friendly. See 23.5.4.5 for ECN-friendliness of - tunnels, and &man.gif.4; for how to configure. + gif can be configured to be ECN-friendly. See 23.5.4.5 for ECN-friendliness + of tunnels, and &man.gif.4; for how to configure. - If you would like to configure an IPv4-in-IPv6 tunnel with gif - interface, read &man.gif.4; carefully. You will need to - remove IPv6 link-local address automatically assigned to the gif - interface. + If you would like to configure an IPv4-in-IPv6 tunnel + with gif interface, read &man.gif.4; carefully. You will + need to remove IPv6 link-local address automatically + assigned to the gif interface. Source Address Selection - Current source selection rule is scope oriented (there are some - exceptions - see below). For a given destination, a source IPv6 - address is selected by the following rule: + Current source selection rule is scope oriented (there + are some exceptions - see below). For a given destination, + a source IPv6 address is selected by the following + rule: - If the source address is explicitly specified by - the user (e.g. via the advanced API), the specified address - is used. + If the source address is explicitly specified by the + user (e.g., via the advanced API), the specified + address is used. If there is an address assigned to the outgoing - interface (which is usually determined by looking up the - routing table) that has the same scope as the destination - address, the address is used. + interface (which is usually determined by looking up the + routing table) that has the same scope as the + destination address, the address is used. This is the most typical case. If there is no address that satisfies the above - condition, choose a global address assigned to one of - the interfaces on the sending node. + condition, choose a global address assigned to one of + the interfaces on the sending node. - If there is no address that satisfies the above condition, - and destination address is site local scope, choose a site local - address assigned to one of the interfaces on the sending node. - *** DIFF OUTPUT TRUNCATED AT 1000 LINES *** From owner-svn-doc-head@freebsd.org Sun Aug 26 15:56:46 2018 Return-Path: Delivered-To: svn-doc-head@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 421CC1079F0F; Sun, 26 Aug 2018 15:56:46 +0000 (UTC) (envelope-from bcr@FreeBSD.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mxrelay.nyi.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id DE88A8503D; Sun, 26 Aug 2018 15:56:45 +0000 (UTC) (envelope-from bcr@FreeBSD.org) Received: from repo.freebsd.org (repo.freebsd.org [IPv6:2610:1c1:1:6068::e6a:0]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id BC45A110F0; Sun, 26 Aug 2018 15:56:45 +0000 (UTC) (envelope-from bcr@FreeBSD.org) Received: from repo.freebsd.org ([127.0.1.37]) by repo.freebsd.org (8.15.2/8.15.2) with ESMTP id w7QFuj3v027787; Sun, 26 Aug 2018 15:56:45 GMT (envelope-from bcr@FreeBSD.org) Received: (from bcr@localhost) by repo.freebsd.org (8.15.2/8.15.2/Submit) id w7QFujta027786; Sun, 26 Aug 2018 15:56:45 GMT (envelope-from bcr@FreeBSD.org) Message-Id: <201808261556.w7QFujta027786@repo.freebsd.org> X-Authentication-Warning: repo.freebsd.org: bcr set sender to bcr@FreeBSD.org using -f From: Benedict Reuschling Date: Sun, 26 Aug 2018 15:56:45 +0000 (UTC) To: doc-committers@freebsd.org, svn-doc-all@freebsd.org, svn-doc-head@freebsd.org Subject: svn commit: r52176 - head/en_US.ISO8859-1/books/arch-handbook/jail X-SVN-Group: doc-head X-SVN-Commit-Author: bcr X-SVN-Commit-Paths: head/en_US.ISO8859-1/books/arch-handbook/jail X-SVN-Commit-Revision: 52176 X-SVN-Commit-Repository: doc MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-BeenThere: svn-doc-head@freebsd.org X-Mailman-Version: 2.1.27 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, 26 Aug 2018 15:56:46 -0000 Author: bcr Date: Sun Aug 26 15:56:45 2018 New Revision: 52176 URL: https://svnweb.freebsd.org/changeset/doc/52176 Log: Clean up some errors that were reported by textproc/igor: - Bad tag indents - Wrap long lines - Two spaces at sentence start Modified: head/en_US.ISO8859-1/books/arch-handbook/jail/chapter.xml Modified: head/en_US.ISO8859-1/books/arch-handbook/jail/chapter.xml ============================================================================== --- head/en_US.ISO8859-1/books/arch-handbook/jail/chapter.xml Sun Aug 26 14:08:19 2018 (r52175) +++ head/en_US.ISO8859-1/books/arch-handbook/jail/chapter.xml Sun Aug 26 15:56:45 2018 (r52176) @@ -4,53 +4,68 @@ $FreeBSD$ --> - - The Jail Subsystem - EvanSarmiento -
evms@cs.bu.edu
- + + + The Jail Subsystem + + + + Evan + Sarmiento + + +
+ evms@cs.bu.edu +
+ + 2001 Evan Sarmiento - security Jail root - On most &unix; systems, root has omnipotent power. - This promotes insecurity. If an attacker gained root - on a system, he would have every function at his fingertips. In FreeBSD - there are sysctls which dilute the power of root, in - order to minimize the damage caused by an attacker. Specifically, one of - these functions is called secure levels. Similarly, - another function which is present from FreeBSD 4.0 and onward, is a utility - called &man.jail.8;. Jail chroots an environment - and sets certain restrictions on processes which are forked within - the jail. For example, a jailed process - cannot affect processes outside the jail, - utilize certain system calls, or inflict any damage on the host - environment. + On most &unix; systems, root has omnipotent + power. This promotes insecurity. If an attacker gained + root on a system, he would have every function + at his fingertips. In FreeBSD there are sysctls which dilute the + power of root, in order to minimize the damage + caused by an attacker. Specifically, one of these functions is + called secure levels. Similarly, another + function which is present from FreeBSD 4.0 and onward, is a + utility called &man.jail.8;. Jail + chroots an environment and sets certain restrictions on processes + which are forked within the jail. For + example, a jailed process cannot affect processes outside the + jail, utilize certain system calls, or + inflict any damage on the host environment. Jail is becoming the new security - model. People are running potentially vulnerable servers such as - Apache, BIND, and - sendmail within jails, so that if an attacker - gains root within the jail, - it is only an annoyance, and not a devastation. This article mainly - focuses on the internals (source code) of jail. - For information on how to set up a jail see the handbook entry on jails. + model. People are running potentially vulnerable servers such as + Apache, + BIND, and + sendmail within jails, so that if an + attacker gains root within the + jail, it is only an annoyance, and not + a devastation. This article mainly focuses on the internals + (source code) of jail. For information + on how to set up a jail see the handbook entry on + jails. Architecture - - Jail consists of two realms: the + Jail consists of two realms: the userland program, &man.jail.8;, and the code implemented within the kernel: the &man.jail.2; system call and associated - restrictions. I will be discussing the userland program and + restrictions. I will be discussing the userland program and then how jail is implemented within the kernel. @@ -60,24 +75,25 @@ Jail Userland Program - The source for the userland jail - is located in /usr/src/usr.sbin/jail, - consisting of one file, jail.c. The program - takes these arguments: the path of the jail, - hostname, IP address, and the command to be executed. + The source for the userland + jail is located in + /usr/src/usr.sbin/jail, consisting of one + file, jail.c. The program takes these + arguments: the path of the jail, + hostname, IP address, and the command to be executed. - Data Structures + Data Structures - In jail.c, the first thing I would - note is the declaration of an important structure - struct jail j; which was included from - /usr/include/sys/jail.h. + In jail.c, the first thing I would + note is the declaration of an important structure + struct jail j; which was included from + /usr/include/sys/jail.h. - The definition of the jail structure is: - + The definition of the jail structure + is: -/usr/include/sys/jail.h: + /usr/include/sys/jail.h: struct jail { u_int32_t version; @@ -86,11 +102,11 @@ struct jail { u_int32_t ip_number; }; - As you can see, there is an entry for each of the - arguments passed to the &man.jail.8; program, and indeed, - they are set during its execution. + As you can see, there is an entry for each of the + arguments passed to the &man.jail.8; program, and indeed, + they are set during its execution. - /usr/src/usr.sbin/jail/jail.c + /usr/src/usr.sbin/jail/jail.c char path[PATH_MAX]; ... if (realpath(argv[0], path) == NULL) @@ -101,54 +117,55 @@ memset(&j, 0, sizeof(j)); j.version = 0; j.path = path; j.hostname = argv[1]; - - Networking + Networking - One of the arguments passed to the &man.jail.8; program is - an IP address with which the jail - can be accessed over the network. &man.jail.8; translates the - IP address given into host byte order and then stores it in - j (the jail structure). + One of the arguments passed to the &man.jail.8; program + is an IP address with which the + jail can be accessed over the + network. &man.jail.8; translates the IP address given into + host byte order and then stores it in j + (the jail structure). - /usr/src/usr.sbin/jail/jail.c: + /usr/src/usr.sbin/jail/jail.c: struct in_addr in; ... if (inet_aton(argv[2], &in) == 0) errx(1, "Could not make sense of ip-number: %s", argv[2]); j.ip_number = ntohl(in.s_addr); - The &man.inet.aton.3; function "interprets the specified - character string as an Internet address, placing the address - into the structure provided." The ip_number - member in the jail structure is set only - when the IP address placed onto the in - structure by &man.inet.aton.3; is translated into host byte - order by &man.ntohl.3;. - + The &man.inet.aton.3; function "interprets the specified + character string as an Internet address, placing the address + into the structure provided." The + ip_number member in the + jail structure is set only when the IP + address placed onto the in structure by + &man.inet.aton.3; is translated into host byte order by + &man.ntohl.3;. - Jailing the Process + Jailing the Process - Finally, the userland program jails the process. - Jail now becomes an imprisoned - process itself and then executes the command given using - &man.execv.3;. - /usr/src/usr.sbin/jail/jail.c + Finally, the userland program jails the process. + Jail now becomes an imprisoned + process itself and then executes the command given using + &man.execv.3;. + + /usr/src/usr.sbin/jail/jail.c i = jail(&j); ... if (execv(argv[3], argv + 3) != 0) err(1, "execv: %s", argv[3]); - As you can see, the jail() function is - called, and its argument is the jail structure - which has been filled with the arguments given to the program. - Finally, the program you specify is executed. I will now discuss - how jail is implemented within the - kernel. + As you can see, the jail() function + is called, and its argument is the jail + structure which has been filled with the arguments given to + the program. Finally, the program you specify is executed. + I will now discuss how jail is + implemented within the kernel. @@ -159,20 +176,19 @@ if (execv(argv[3], argv + 3) != 0) Kernel Architecture We will now be looking at the file - /usr/src/sys/kern/kern_jail.c. This is - the file where the &man.jail.2; system call, appropriate sysctls, - and networking functions are defined. + /usr/src/sys/kern/kern_jail.c. This is + the file where the &man.jail.2; system call, appropriate + sysctls, and networking functions are defined. - sysctls + Sysctls - sysctl + sysctl - In kern_jail.c, the following - sysctls are defined: + In kern_jail.c, the following + sysctls are defined: - /usr/src/sys/kern/kern_jail.c: - + /usr/src/sys/kern/kern_jail.c: int jail_set_hostname_allowed = 1; SYSCTL_INT(_security_jail, OID_AUTO, set_hostname_allowed, CTLFLAG_RW, &jail_set_hostname_allowed, 0, @@ -208,29 +224,30 @@ SYSCTL_INT(_security_jail, OID_AUTO, mount_allowed, CT &jail_mount_allowed, 0, "Processes in jail can mount/unmount jail-friendly file systems"); - Each of these sysctls can be accessed by the user - through the &man.sysctl.8; program. Throughout the kernel, these - specific sysctls are recognized by their name. For example, - the name of the first sysctl is - security.jail.set_hostname_allowed. + Each of these sysctls can be accessed by the user + through the &man.sysctl.8; program. Throughout the kernel, + these specific sysctls are recognized by their name. For + example, the name of the first sysctl is + security.jail.set_hostname_allowed. - &man.jail.2; System Call + &man.jail.2; System Call - Like all system calls, the &man.jail.2; system call takes - two arguments, struct thread *td and - struct jail_args *uap. - td is a pointer to the thread - structure which describes the calling thread. In this - context, uap is a pointer to the structure - in which a pointer to the jail structure - passed by the userland jail.c is contained. - When I described the userland program before, you saw that the - &man.jail.2; system call was given a jail - structure as its own argument. + Like all system calls, the &man.jail.2; system call + takes two arguments, struct thread *td + and struct jail_args *uap. + td is a pointer to the + thread structure which describes the + calling thread. In this context, uap is + a pointer to the structure in which a pointer to the + jail structure passed by the userland + jail.c is contained. When I described + the userland program before, you saw that the &man.jail.2; + system call was given a jail structure as + its own argument. - /usr/src/sys/kern/kern_jail.c: + /usr/src/sys/kern/kern_jail.c: /* * struct jail_args { * struct jail *jail; @@ -239,29 +256,30 @@ SYSCTL_INT(_security_jail, OID_AUTO, mount_allowed, CT int jail(struct thread *td, struct jail_args *uap) - Therefore, uap->jail can be used to - access the jail structure which was passed - to the system call. Next, the system call copies the - jail structure into kernel space using - the &man.copyin.9; function. &man.copyin.9; takes three arguments: - the address of the data which is to be copied into kernel space, - uap->jail, where to store it, - j and the size of the storage. The - jail structure pointed by - uap->jail is copied into kernel space and - is stored in another jail structure, - j. + Therefore, uap->jail can be used + to access the jail structure which was + passed to the system call. Next, the system call copies the + jail structure into kernel space using + the &man.copyin.9; function. &man.copyin.9; takes three + arguments: the address of the data which is to be copied + into kernel space, uap->jail, where to + store it, j and the size of the storage. + The jail structure pointed by + uap->jail is copied into kernel space + and is stored in another jail structure, + j. - /usr/src/sys/kern/kern_jail.c: + /usr/src/sys/kern/kern_jail.c: error = copyin(uap->jail, &j, sizeof(j)); - There is another important structure defined in - jail.h. It is the prison - structure. The prison structure is used - exclusively within kernel space. Here is the definition of the - prison structure. + There is another important structure defined in + jail.h. It is the + prison structure. The + prison structure is used exclusively + within kernel space. Here is the definition of the + prison structure. - /usr/include/sys/jail.h: + /usr/include/sys/jail.h: struct prison { LIST_ENTRY(prison) pr_list; /* (a) all prisons */ int pr_id; /* (c) prison id */ @@ -277,12 +295,12 @@ struct prison { void **pr_slots; /* (p) additional data */ }; - The &man.jail.2; system call then allocates memory for - a prison structure and copies data between - the jail and prison - structure. + The &man.jail.2; system call then allocates memory for a + prison structure and copies data between + the jail and prison + structure. - /usr/src/sys/kern/kern_jail.c: + /usr/src/sys/kern/kern_jail.c: MALLOC(pr, struct prison *, sizeof(*pr), M_PRISON, M_WAITOK | M_ZERO); ... error = copyinstr(j.path, &pr->pr_path, sizeof(pr->pr_path), 0); @@ -293,10 +311,12 @@ error = copyinstr(j.hostname, &pr->pr_host, siz if (error) goto e_dropvnref; pr->pr_ip = j.ip_number; - Next, we will discuss another important system call - &man.jail.attach.2;, which implements the function to put - a process into the jail. - /usr/src/sys/kern/kern_jail.c: + + Next, we will discuss another important system call + &man.jail.attach.2;, which implements the function to put a + process into the jail. + + /usr/src/sys/kern/kern_jail.c: /* * struct jail_attach_args { * int jid; @@ -304,34 +324,37 @@ pr->pr_ip = j.ip_number; */ int jail_attach(struct thread *td, struct jail_attach_args *uap) - This system call makes the changes that can distinguish - a jailed process from those unjailed ones. - To understand what &man.jail.attach.2; does for us, certain - background information is needed. - - On FreeBSD, each kernel visible thread is identified by its - thread structure, while the processes are - described by their proc structures. You can - find the definitions of the thread and - proc structure in - /usr/include/sys/proc.h. - For example, the td argument in any system - call is actually a pointer to the calling thread's - thread structure, as stated before. - The td_proc member in the - thread structure pointed by td - is a pointer to the proc structure which - represents the process that contains the thread represented by - td. The proc structure - contains members which can describe the owner's - identity(p_ucred), the process resource - limits(p_limit), and so on. In the - ucred structure pointed by - p_ucred member in the proc - structure, there is a pointer to the prison - structure(cr_prison). - /usr/include/sys/proc.h: + This system call makes the changes that can distinguish + a jailed process from those unjailed ones. To understand + what &man.jail.attach.2; does for us, certain background + information is needed. + + On FreeBSD, each kernel visible thread is identified by + its thread structure, while the processes + are described by their proc structures. + You can find the definitions of the + thread and proc + structure in /usr/include/sys/proc.h. + For example, the td argument in any + system call is actually a pointer to the calling thread's + thread structure, as stated before. The + td_proc member in the + thread structure pointed by + td is a pointer to the + proc structure which represents the + process that contains the thread represented by + td. The proc + structure contains members which can describe the owner's + identity(p_ucred), the process resource + limits(p_limit), and so on. In the + ucred structure pointed by + p_ucred member in the + proc structure, there is a pointer to the + prison + structure(cr_prison). + + /usr/include/sys/proc.h: struct thread { ... struct proc *td_proc; @@ -349,29 +372,33 @@ struct ucred { ... }; - In kern_jail.c, the function - jail() then calls function - jail_attach() with a given jid. - And jail_attach() calls function - change_root() to change the root directory of the - calling process. The jail_attach() then creates - a new ucred structure, and attaches the newly - created ucred structure to the calling process - after it has successfully attached the prison - structure to the ucred structure. From then on, - the calling process is recognized as jailed. When the kernel routine - jailed() is called in the kernel with the newly - created ucred structure as its argument, it - returns 1 to tell that the credential is connected - with a jail. The public ancestor process - of all the process forked within the jail, - is the process which runs &man.jail.8;, as it calls the - &man.jail.2; system call. When a program is executed through - &man.execve.2;, it inherits the jailed property of its parent's - ucred structure, therefore it has a jailed - ucred structure. + In kern_jail.c, the function + jail() then calls function + jail_attach() with a given + jid. And + jail_attach() calls function + change_root() to change the root + directory of the calling process. The + jail_attach() then creates a new + ucred structure, and attaches the newly + created ucred structure to the calling + process after it has successfully attached the + prison structure to the + ucred structure. From then on, the + calling process is recognized as jailed. When the kernel + routine jailed() is called in the kernel + with the newly created ucred structure as + its argument, it returns 1 to tell that the credential is + connected with a jail. The + public ancestor process of all the process forked within the + jail, is the process which runs + &man.jail.8;, as it calls the &man.jail.2; system call. + When a program is executed through &man.execve.2;, it + inherits the jailed property of its parent's + ucred structure, therefore it has a + jailed ucred structure. - /usr/src/sys/kern/kern_jail.c + /usr/src/sys/kern/kern_jail.c int jail(struct thread *td, struct jail_args *uap) { @@ -401,17 +428,18 @@ jail_attach(struct thread *td, struct jail_attach_args p->p_ucred = newcred; ... } - When a process is forked from its parent process, the - &man.fork.2; system call uses crhold() to - maintain the credential for the newly forked process. It inherently - keep the newly forked child's credential consistent with its parent, - so the child process is also jailed. - /usr/src/sys/kern/kern_fork.c: + When a process is forked from its parent process, the + &man.fork.2; system call uses crhold() to + maintain the credential for the newly forked process. It + inherently keep the newly forked child's credential + consistent with its parent, so the child process is also + jailed. + + /usr/src/sys/kern/kern_fork.c: p2->p_ucred = crhold(td->td_ucred); ... td2->td_ucred = crhold(p2->p_ucred); - @@ -420,12 +448,11 @@ td2->td_ucred = crhold(p2->p_ucred);Restrictions Throughout the kernel there are access restrictions relating - to jailed processes. Usually, these restrictions only check whether - the process is jailed, and if so, returns an error. For + to jailed processes. Usually, these restrictions only check + whether the process is jailed, and if so, returns an error. For example: - -if (jailed(td->td_ucred)) + if (jailed(td->td_ucred)) return (EPERM); @@ -433,112 +460,128 @@ if (jailed(td->td_ucred)) System V IPC - System V IPC is based on messages. Processes can send each - other these messages which tell them how to act. The functions - which deal with messages are: - &man.msgctl.3;, &man.msgget.3;, &man.msgsnd.3; and &man.msgrcv.3;. - Earlier, I mentioned that there were certain sysctls you could - turn on or off in order to affect the behavior of - jail. One of these sysctls was - security.jail.sysvipc_allowed. By default, - this sysctl is set to 0. If it were set to 1, it would defeat the - whole purpose of having a jail; privileged - users from the jail would be able to - affect processes outside the jailed environment. The difference - between a message and a signal is that the message only consists - of the signal number. + System V IPC is based on messages. Processes can send + each other these messages which tell them how to act. The + functions which deal with messages are: &man.msgctl.3;, + &man.msgget.3;, &man.msgsnd.3; and &man.msgrcv.3;. Earlier, I + mentioned that there were certain sysctls you could turn on or + off in order to affect the behavior of + jail. One of these sysctls was + security.jail.sysvipc_allowed. By default, + this sysctl is set to 0. If it were set to 1, it would defeat + the whole purpose of having a jail; + privileged users from the jail + would be able to affect processes outside the jailed + environment. The difference between a message and a signal is + that the message only consists of the signal number. /usr/src/sys/kern/sysv_msg.c: - msgget(key, msgflg): - msgget returns (and possibly creates) a message - descriptor that designates a message queue for use in other - functions. + + msgget(key, msgflg): + msgget returns (and possibly creates) a + message descriptor that designates a message queue for use + in other functions. + - msgctl(msgid, cmd, buf): - Using this function, a process can query the status of a message - descriptor. + + msgctl(msgid, cmd, buf): Using this + function, a process can query the status of a message + descriptor. + - msgsnd(msgid, msgp, msgsz, msgflg): - msgsnd sends a message to a - process. + + msgsnd(msgid, msgp, msgsz, msgflg): + msgsnd sends a message to a + process. + - msgrcv(msgid, msgp, msgsz, msgtyp, - msgflg): a process receives messages using - this function - + + msgrcv(msgid, msgp, msgsz, msgtyp, + msgflg): a process receives messages using + this function + - In each of the system calls corresponding to these functions, - there is this conditional: + In each of the system calls corresponding to these + functions, there is this conditional: /usr/src/sys/kern/sysv_msg.c: if (!jail_sysvipc_allowed && jailed(td->td_ucred)) return (ENOSYS); semaphores + Semaphore system calls allow processes to synchronize - execution by doing a set of operations atomically on a set of - semaphores. Basically semaphores provide another way for - processes lock resources. However, process waiting on a - semaphore, that is being used, will sleep until the resources - are relinquished. The following semaphore system calls are - blocked inside a jail: &man.semget.2;, - &man.semctl.2; and &man.semop.2;. + execution by doing a set of operations atomically on a set of + semaphores. Basically semaphores provide another way for + processes lock resources. However, process waiting on a + semaphore, that is being used, will sleep until the resources + are relinquished. The following semaphore system calls are + blocked inside a jail: + &man.semget.2;, &man.semctl.2; and &man.semop.2;. /usr/src/sys/kern/sysv_sem.c: - - semctl(semid, semnum, cmd, ...): - semctl does the specified cmd - on the semaphore queue indicated by - semid. + + semctl(semid, semnum, cmd, ...): + semctl does the specified + cmd on the semaphore queue indicated by + semid. - - semget(key, nsems, flag): - semget creates an array of semaphores, - corresponding to key. + + semget(key, nsems, flag): + semget creates an array of semaphores, + corresponding to key. - key and flag take on the same meaning as they - do in msgget. + key and flag take on the same meaning as they + do in msgget. + - semop(semid, array, nops): - semop performs a group of operations indicated - by array, to the set of semaphores identified by - semid. + semop(semid, array, nops): + semop performs a group of operations + indicated by array, to the set of + semaphores identified by + semid. shared memory - System V IPC allows for processes to share - memory. Processes can communicate directly with each other by - sharing parts of their virtual address space and then reading - and writing data stored in the shared memory. These system - calls are blocked within a jailed environment: &man.shmdt.2;, - &man.shmat.2;, &man.shmctl.2; and &man.shmget.2;. + System V IPC allows for processes to share memory. + Processes can communicate directly with each other by sharing + parts of their virtual address space and then reading and + writing data stored in the shared memory. These system calls + are blocked within a jailed environment: &man.shmdt.2;, + &man.shmat.2;, &man.shmctl.2; and &man.shmget.2;. + /usr/src/sys/kern/sysv_shm.c: - shmctl(shmid, cmd, buf): - shmctl does various control operations on the - shared memory region identified by - shmid. + shmctl(shmid, cmd, buf): + shmctl does various control operations + on the shared memory region identified by + shmid. + - shmget(key, size, flag): - shmget accesses or creates a shared memory - region of size bytes. + shmget(key, size, flag): + shmget accesses or creates a shared + memory region of size + bytes. + - shmat(shmid, addr, flag): - shmat attaches a shared memory region identified - by shmid to the address space of a - process. + shmat(shmid, addr, flag): + shmat attaches a shared memory region + identified by shmid to the address + space of a process. + - shmdt(addr): - shmdt detaches the shared memory region - previously attached at addr. - + shmdt(addr): + shmdt detaches the shared memory region + previously attached at + addr. + @@ -546,17 +589,18 @@ if (!jail_sysvipc_allowed && jailed(td->td_ Sockets sockets - Jail treats the &man.socket.2; system - call and related lower-level socket functions in a special manner. - In order to determine whether a certain socket is allowed to be - created, it first checks to see if the sysctl - security.jail.socket_unixiproute_only is set. If - set, sockets are only allowed to be created if the family - specified is either PF_LOCAL, - PF_INET or - PF_ROUTE. Otherwise, it returns an - error. + Jail treats the &man.socket.2; + system call and related lower-level socket functions in a + special manner. In order to determine whether a certain + socket is allowed to be created, it first checks to see if the + sysctl + security.jail.socket_unixiproute_only is + set. If set, sockets are only allowed to be created if the + family specified is either PF_LOCAL, + PF_INET or PF_ROUTE. + Otherwise, it returns an error. + /usr/src/sys/kern/uipc_socket.c: int socreate(int dom, struct socket **aso, int type, int proto, @@ -572,7 +616,6 @@ socreate(int dom, struct socket **aso, int type, int p } ... } - @@ -581,10 +624,11 @@ socreate(int dom, struct socket **aso, int type, int p Berkeley Packet Filter data link layer - The Berkeley Packet Filter provides - a raw interface to data link layers in a protocol independent - fashion. BPF is now controlled by the - &man.devfs.8; whether it can be used in a jailed environment. + The Berkeley Packet Filter + provides a raw interface to data link layers in a protocol + independent fashion. BPF is now + controlled by the &man.devfs.8; whether it can be used in a + jailed environment. @@ -594,23 +638,25 @@ socreate(int dom, struct socket **aso, int type, int p protocols There are certain protocols which are very common, such as - TCP, UDP, IP and ICMP. IP and ICMP are on the same level: the - network layer 2. There are certain precautions which are - taken in order to prevent a jailed process from binding a - protocol to a certain address only if the nam - parameter is set. nam is a pointer to a - sockaddr structure, - which describes the address on which to bind the service. A - more exact definition is that sockaddr "may be - used as a template for referring to the identifying tag and length of - each address". In the function - in_pcbbind_setup(), sin is a - pointer to a sockaddr_in structure, which - contains the port, address, length and domain family of the socket - which is to be bound. Basically, this disallows any processes from - jail to be able to specify the address - that does not belong to the jail in which - the calling process exists. + TCP, UDP, IP and ICMP. IP and ICMP are on the same level: the + network layer 2. There are certain precautions which are + taken in order to prevent a jailed process from binding a + protocol to a certain address only if the + nam parameter is set. + nam is a pointer to a + sockaddr structure, which describes the + address on which to bind the service. A more exact definition + is that sockaddr "may be used as a template + for referring to the identifying tag and length of each + address". In the function + in_pcbbind_setup(), sin + is a pointer to a sockaddr_in structure, + which contains the port, address, length and domain family of + the socket which is to be bound. Basically, this disallows + any processes from jail to be able + to specify the address that does not belong to the + jail in which the calling process + exists. /usr/src/sys/netinet/in_pcb.c: int @@ -648,14 +694,15 @@ in_pcbbind_setup(struct inpcb *inp, struct sockaddr *n } You might be wondering what function - prison_ip() does. prison_ip() - is given three arguments, a pointer to the credential(represented by - cred), any flags, and an IP address. It - returns 1 if the IP address does NOT belong to the - jail or 0 otherwise. As you can see - from the code, if it is indeed an IP address not belonging to the - jail, the protocol is not allowed to bind - to that address. + prison_ip() does. + prison_ip() is given three arguments, a + pointer to the credential(represented by + cred), any flags, and an IP address. It + returns 1 if the IP address does NOT belong to the + jail or 0 otherwise. As you can + see from the code, if it is indeed an IP address not belonging + to the jail, the protocol is not + allowed to bind to that address. /usr/src/sys/kern/kern_jail.c: int @@ -693,10 +740,12 @@ prison_ip(struct ucred *cred, int flag, u_int32_t *ip) Filesystem filesystem + Even root users within the - jail are not allowed to unset or modify - any file flags, such as immutable, append-only, and undeleteable - flags, if the securelevel is greater than 0. + jail are not allowed to unset or + modify any file flags, such as immutable, append-only, and + undeleteable flags, if the securelevel is greater than + 0. /usr/src/sys/ufs/ufs/ufs_vnops.c: static int @@ -741,7 +790,5 @@ prison_priv_check(struct ucred *cred, int priv) ... } - - From owner-svn-doc-head@freebsd.org Sun Aug 26 18:34:51 2018 Return-Path: Delivered-To: svn-doc-head@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 16D07107DFAF; Sun, 26 Aug 2018 18:34:51 +0000 (UTC) (envelope-from bcr@FreeBSD.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mxrelay.nyi.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id C04078B128; Sun, 26 Aug 2018 18:34:50 +0000 (UTC) (envelope-from bcr@FreeBSD.org) Received: from repo.freebsd.org (repo.freebsd.org [IPv6:2610:1c1:1:6068::e6a:0]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id A23ED12ACC; Sun, 26 Aug 2018 18:34:50 +0000 (UTC) (envelope-from bcr@FreeBSD.org) Received: from repo.freebsd.org ([127.0.1.37]) by repo.freebsd.org (8.15.2/8.15.2) with ESMTP id w7QIYo9f009735; Sun, 26 Aug 2018 18:34:50 GMT (envelope-from bcr@FreeBSD.org) Received: (from bcr@localhost) by repo.freebsd.org (8.15.2/8.15.2/Submit) id w7QIYoBa009734; Sun, 26 Aug 2018 18:34:50 GMT (envelope-from bcr@FreeBSD.org) Message-Id: <201808261834.w7QIYoBa009734@repo.freebsd.org> X-Authentication-Warning: repo.freebsd.org: bcr set sender to bcr@FreeBSD.org using -f From: Benedict Reuschling Date: Sun, 26 Aug 2018 18:34:50 +0000 (UTC) To: doc-committers@freebsd.org, svn-doc-all@freebsd.org, svn-doc-head@freebsd.org Subject: svn commit: r52177 - head/en_US.ISO8859-1/books/developers-handbook/sockets X-SVN-Group: doc-head X-SVN-Commit-Author: bcr X-SVN-Commit-Paths: head/en_US.ISO8859-1/books/developers-handbook/sockets X-SVN-Commit-Revision: 52177 X-SVN-Commit-Repository: doc MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-BeenThere: svn-doc-head@freebsd.org X-Mailman-Version: 2.1.27 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, 26 Aug 2018 18:34:51 -0000 Author: bcr Date: Sun Aug 26 18:34:50 2018 New Revision: 52177 URL: https://svnweb.freebsd.org/changeset/doc/52177 Log: Correct errors reported by textproc/igor: - wrap long lines - add two spaces after a sentence stop - use tabs instead of spaces - bad tag indent Modified: head/en_US.ISO8859-1/books/developers-handbook/sockets/chapter.xml Modified: head/en_US.ISO8859-1/books/developers-handbook/sockets/chapter.xml ============================================================================== --- head/en_US.ISO8859-1/books/developers-handbook/sockets/chapter.xml Sun Aug 26 15:56:45 2018 (r52176) +++ head/en_US.ISO8859-1/books/developers-handbook/sockets/chapter.xml Sun Aug 26 18:34:50 2018 (r52177) @@ -4,29 +4,37 @@ $FreeBSD$ --> - - Sockets + + + Sockets + - G. AdamStanislavContributed by + + + G. Adam + Stanislav + + Contributed by + - - Synopsis BSD sockets take interprocess - communications to a new level. It is no longer necessary for the - communicating processes to run on the same machine. They still - can, but they do not have to. + communications to a new level. It is no longer necessary for + the communicating processes to run on the same machine. They + still can, but they do not have to. Not only do these processes not have to run on the same machine, they do not have to run under the same operating - system. Thanks to BSD sockets, your FreeBSD + system. Thanks to BSD sockets, your FreeBSD software can smoothly cooperate with a program running on a - &macintosh;, another one running on a &sun; workstation, yet another - one running under &windows; 2000, all connected with an + &macintosh;, another one running on a &sun; workstation, yet + another one running under &windows; 2000, all connected with an Ethernet-based local area network. But your software can equally well cooperate with processes @@ -44,40 +52,40 @@ Networking and Diversity We have already hinted on the diversity - of networking. Many different systems have to talk to each - other. And they have to speak the same language. They also have - to understand the same language the same - way. + of networking. Many different systems have to talk to each + other. And they have to speak the same language. They also + have to understand the same language the + same way. People often think that body language - is universal. But it is not. Back in my early teens, my father - took me to Bulgaria. We were sitting at a table in a park in + is universal. But it is not. Back in my early teens, my father + took me to Bulgaria. We were sitting at a table in a park in Sofia, when a vendor approached us trying to sell us some roasted almonds. I had not learned much Bulgarian by then, so, instead of saying no, I shook my head from side to side, the universal body language for - no. The vendor quickly started serving us + no. The vendor quickly started serving us some almonds. I then remembered I had been told that in Bulgaria shaking - your head sideways meant yes. Quickly, I - started nodding my head up and down. The vendor noticed, took - his almonds, and walked away. To an uninformed observer, I did + your head sideways meant yes. Quickly, I + started nodding my head up and down. The vendor noticed, took + his almonds, and walked away. To an uninformed observer, I did not change the body language: I continued using the language of - shaking and nodding my head. What changed was the - meaning of the body language. At first, the - vendor and I interpreted the same language as having completely - different meaning. I had to adjust my own interpretation of that - language so the vendor would understand. + shaking and nodding my head. What changed was the + meaning of the body language. At first, + the vendor and I interpreted the same language as having + completely different meaning. I had to adjust my own + interpretation of that language so the vendor would + understand. It is the same with computers: The same symbols may have - different, even outright opposite meaning. Therefore, for - two computers to understand each other, they must not only - agree on the same language, but on the - same interpretation of the language. - + different, even outright opposite meaning. Therefore, for two + computers to understand each other, they must not only agree on + the same language, but on the same + interpretation of the language. @@ -86,7 +94,7 @@ While various programming languages tend to have complex syntax and use a number of multi-letter reserved words (which makes them easy for the human programmer to understand), the - languages of data communications tend to be very terse. Instead + languages of data communications tend to be very terse. Instead of multi-byte words, they often use individual bits. There is a very convincing reason for it: While data travels inside your @@ -98,7 +106,7 @@ protocols rather than languages. As data travels from one computer to another, it always uses - more than one protocol. These protocols are + more than one protocol. These protocols are layered. The data can be compared to the inside of an onion: You have to peel off several layers of skin to get to the data. This is best @@ -106,11 +114,11 @@ - + - +----------------+ + +----------------+ | Ethernet | |+--------------+| || IP || @@ -131,7 +139,7 @@ - Protocol Layers + Protocol Layers @@ -153,7 +161,7 @@ I think you get the picture... To inform our software how to handle the raw data, it is - encoded as a PNG file. It could be a + encoded as a PNG file. It could be a GIF, or a JPEG, but it is a PNG. @@ -161,13 +169,13 @@ At this point, I can hear some of you yelling, No, it is not! It is a file - format! + format! - Well, of course it is a file format. But from the + Well, of course it is a file format. But from the perspective of data communications, a file format is a protocol: The file structure is a language, a terse one at that, communicating to our process - how the data is organized. Ergo, it is a + how the data is organized. Ergo, it is a protocol. Alas, if all we received was the PNG @@ -179,63 +187,63 @@ JPEG, or some other image format? To obtain that information, we are using another protocol: - HTTP. This protocol can tell us exactly that + HTTP. This protocol can tell us exactly that the data represents an image, and that it uses the - PNG protocol. It can also tell us some other - things, but let us stay focused on protocol layers here. - + PNG protocol. It can also tell us some other + things, but let us stay focused on protocol layers here. - So, now we have some data wrapped in the PNG - protocol, wrapped in the HTTP protocol. - How did we get it from the server? + So, now we have some data wrapped in the + PNG protocol, wrapped in the + HTTP protocol. How did we get it from the + server? By using TCP/IP over Ethernet, that is - how. Indeed, that is three more protocols. Instead of + how. Indeed, that is three more protocols. Instead of continuing inside out, I am now going to talk about Ethernet, simply because it is easier to explain the rest that way. Ethernet is an interesting system of connecting computers in a local area network (LAN). Each computer has a network - interface card (NIC), which has a - unique 48-bit ID called its - address. No two Ethernet - NICs in the world have the same address. - + interface card (NIC), which has + a unique 48-bit ID called its + address. No two Ethernet + NICs in the world have the same + address. These NICs are all connected with each - other. Whenever one computer wants to communicate with another + other. Whenever one computer wants to communicate with another in the same Ethernet LAN, it sends a message - over the network. Every NIC sees the - message. But as part of the Ethernet + over the network. Every NIC sees the + message. But as part of the Ethernet protocol, the data contains the address of - the destination NIC (among other things). So, - only one of all the network interface cards will pay attention - to it, the rest will ignore it. + the destination NIC (among other things). + So, only one of all the network interface cards will pay + attention to it, the rest will ignore it. - But not all computers are connected to the same - network. Just because we have received the data over our - Ethernet does not mean it originated in our own local area - network. It could have come to us from some other network (which - may not even be Ethernet based) connected with our own network - via the Internet. + But not all computers are connected to the same network. + Just because we have received the data over our Ethernet does + not mean it originated in our own local area network. It could + have come to us from some other network (which may not even be + Ethernet based) connected with our own network via the + Internet. All data is transferred over the Internet using IP, which stands for Internet - Protocol. Its basic role is to let us know where in - the world the data has arrived from, and where it is supposed to - go to. It does not guarantee we will + Protocol. Its basic role is to let us know where + in the world the data has arrived from, and where it is supposed + to go to. It does not guarantee we will receive the data, only that we will know where it came from if we do receive it. Even if we do receive the data, IP does not guarantee we will receive various chunks of data in the same - order the other computer has sent it to us. So, we can receive + order the other computer has sent it to us. So, we can receive the center of our image before we receive the upper left corner and after the lower right, for example. It is TCP (Transmission Control - Protocol) that asks the sender to resend any lost + Protocol) that asks the sender to resend any lost data and that places it all into the proper order. All in all, it took five different @@ -248,7 +256,7 @@ Ethernet protocol. Oh, and by the way, there probably were several other - protocols involved somewhere on the way. For example, if our + protocols involved somewhere on the way. For example, if our LAN was connected to the Internet through a dial-up call, it used the PPP protocol over the modem which used one (or several) of the various modem @@ -256,38 +264,38 @@ As a developer you should be asking by now, How am I supposed to handle it - all? + all? Luckily for you, you are not supposed - to handle it all. You are supposed to - handle some of it, but not all of it. Specifically, you need not - worry about the physical connection (in our case Ethernet and - possibly PPP, etc). Nor do you need to handle - the Internet Protocol, or the Transmission Control + to handle it all. You are supposed to + handle some of it, but not all of it. Specifically, you need + not worry about the physical connection (in our case Ethernet + and possibly PPP, etc). Nor do you need to + handle the Internet Protocol, or the Transmission Control Protocol. In other words, you do not have to do anything to receive - the data from the other computer. Well, you do have to + the data from the other computer. Well, you do have to ask for it, but that is almost as simple as opening a file. Once you have received the data, it is up to you to figure - out what to do with it. In our case, you would need to + out what to do with it. In our case, you would need to understand the HTTP protocol and the PNG file structure. To use an analogy, all the internetworking protocols become a gray area: Not so much because we do not understand how it - works, but because we are no longer concerned about it. The + works, but because we are no longer concerned about it. The sockets interface takes care of this gray area for us: - + - +----------------+ + +----------------+ |xxxxEthernetxxxx| |+--------------+| ||xxxxxxIPxxxxxx|| @@ -308,7 +316,7 @@ - Sockets Covered Protocol Layers + Sockets Covered Protocol Layers @@ -325,14 +333,13 @@ BSD sockets are built on the basic &unix; model: Everything is a file. In our example, then, sockets would let us receive an HTTP - file, so to speak. It would then be up to us to + file, so to speak. It would then be up to us to extract the PNG file - from it. - + from it. Because of the complexity of internetworking, we cannot just use the open system call, or - the open() C function. Instead, we need to + the open() C function. Instead, we need to take several steps to opening a socket. Once we do, however, we can start treating the @@ -356,32 +363,30 @@ The Client-Server Difference Typically, one of the ends of a socket-based data - communication is a server, the other is a - client. + communication is a server, the other is a + client. - The Common Elements + The Common Elements - + <function>socket</function> The one function used by both, clients and servers, is - &man.socket.2;. It is declared this way: + &man.socket.2;. It is declared this way: - -int socket(int domain, int type, int protocol); - + int socket(int domain, int type, int protocol); - The return value is of the same type as that of - open, an integer. FreeBSD allocates + The return value is of the same type as that of + open, an integer. FreeBSD allocates its value from the same pool as that of file handles. That is what allows sockets to be treated the same way as files. The domain argument tells the system what protocol family you want - it to use. Many of them exist, some are vendor specific, - others are very common. They are declared in + it to use. Many of them exist, some are vendor specific, + others are very common. They are declared in sys/socket.h. Use PF_INET for @@ -422,25 +427,24 @@ int socket(int domain, int type, int protocol); unconnected. This is on purpose: To use a telephone analogy, we - have just attached a modem to the phone line. We have + have just attached a modem to the phone line. We have neither told the modem to make a call, nor to answer if the phone rings. - + <varname>sockaddr</varname> Various functions of the sockets family expect the - address of (or pointer to, to use C terminology) a small - area of the memory. The various C declarations in the - sys/socket.h refer to it as - struct sockaddr. This structure is - declared in the same file: + address of (or pointer to, to use C terminology) a small + area of the memory. The various C declarations in the + sys/socket.h refer to it as + struct sockaddr. This structure is + declared in the same file: - -/* + /* * Structure used by kernel to store most * addresses. */ @@ -449,17 +453,16 @@ struct sockaddr { sa_family_t sa_family; /* address family */ char sa_data[14]; /* actually longer; address value */ }; -#define SOCK_MAXADDRLEN 255 /* longest possible addresses */ - +#define SOCK_MAXADDRLEN 255 /* longest possible addresses */ - Please note the vagueness with + Please note the vagueness with which the sa_data field is declared, just as an array of 14 bytes, with the comment hinting there can be more than 14 of them. - This vagueness is quite deliberate. Sockets is a very - powerful interface. While most people perhaps think of it + This vagueness is quite deliberate. Sockets is a very + powerful interface. While most people perhaps think of it as nothing more than the Internet interface—and most applications probably use it for that nowadays—sockets can be used for just about @@ -473,8 +476,7 @@ struct sockaddr { right before the definition of sockaddr: - -/* + /* * Address families. */ #define AF_UNSPEC 0 /* unspecified */ @@ -519,11 +521,9 @@ struct sockaddr { #define AF_SCLUSTER 34 /* Sitara cluster protocol */ #define AF_ARP 35 #define AF_BLUETOOTH 36 /* Bluetooth sockets */ -#define AF_MAX 37 +#define AF_MAX 37 - - - The one used for IP is + The one used for IP is AF_INET. It is a symbol for the constant 2. @@ -534,13 +534,12 @@ struct sockaddr { used. Specifically, whenever the address - family is AF_INET, we can use - struct sockaddr_in found in + family is AF_INET, we can + use struct sockaddr_in found in netinet/in.h, wherever sockaddr is expected: - -/* + /* * Socket address, internet style. */ struct sockaddr_in { @@ -549,18 +548,17 @@ struct sockaddr_in { in_port_t sin_port; struct in_addr sin_addr; char sin_zero[8]; -}; - +}; - We can visualize its organization this way: + We can visualize its organization this way: - - - - + + + + - - 0 1 2 3 + + 0 1 2 3 +--------+--------+-----------------+ 0 | 0 | Family | Port | +--------+--------+-----------------+ @@ -570,39 +568,41 @@ struct sockaddr_in { +-----------------------------------+ 12 | 0 | +-----------------------------------+ - + - - sockaddr_in - - + + sockaddr_in + + - The three important fields are + The three important fields are sin_family, which is byte 1 of the structure, sin_port, a 16-bit value found in bytes 2 and 3, and sin_addr, a 32-bit integer representation of the IP address, stored in bytes 4-7. - Now, let us try to fill it out. Let us assume we are + Now, let us try to fill it out. Let us assume we are trying to write a client for the daytime protocol, which simply states that its server will write a text string representing the - current date and time to port 13. We want to use + current date and time to port 13. We want to use TCP/IP, so we need to specify - AF_INET in the address family - field. AF_INET is defined as - 2. Let us use the - IP address of 192.43.244.18, which is the time - server of US federal government (time.nist.gov). + AF_INET in the address family field. + AF_INET is defined as + 2. Let us use the + IP address of 192.43.244.18, which is + the time server of US federal government (time.nist.gov). - - - - + + + + - - 0 1 2 3 + + 0 1 2 3 +--------+--------+-----------------+ 0 | 0 | 2 | 13 | +-----------------+-----------------+ @@ -612,59 +612,58 @@ struct sockaddr_in { +-----------------------------------+ 12 | 0 | +-----------------------------------+ - + - - Specific example of sockaddr_in - - + + Specific example of sockaddr_in + + - By the way the sin_addr field is - declared as being of the struct in_addr - type, which is defined in - netinet/in.h: + By the way the sin_addr field is + declared as being of the struct in_addr + type, which is defined in + netinet/in.h: - -/* + /* * Internet address (a structure for historical reasons) */ struct in_addr { in_addr_t s_addr; -}; - +}; - In addition, in_addr_t is a 32-bit - integer. + In addition, in_addr_t is a 32-bit + integer. - The 192.43.244.18 is - just a convenient notation of expressing a 32-bit integer - by listing all of its 8-bit bytes, starting with the + The 192.43.244.18 is just a + convenient notation of expressing a 32-bit integer by + listing all of its 8-bit bytes, starting with the most significant one. - So far, we have viewed sockaddr as + So far, we have viewed sockaddr as an abstraction. Our computer does not store short integers as a single 16-bit - entity, but as a sequence of 2 bytes. Similarly, it stores - 32-bit integers as a sequence of 4 bytes. + entity, but as a sequence of 2 bytes. Similarly, it + stores 32-bit integers as a sequence of 4 bytes. - Suppose we coded something like this: + Suppose we coded something like this: sa.sin_family = AF_INET; sa.sin_port = 13; sa.sin_addr.s_addr = (((((192 << 8) | 43) << 8) | 244) << 8) | 18; - What would the result look like? + What would the result look like? - Well, that depends, of course. On a &pentium;, or other - x86, based computer, it would look like this: + Well, that depends, of course. On a &pentium;, or + other x86, based computer, it would look like this: - - - - + + + + - - 0 1 2 3 + + 0 1 2 3 +--------+--------+--------+--------+ 0 | 0 | 2 | 13 | 0 | +--------+--------+--------+--------+ @@ -674,23 +673,22 @@ sa.sin_addr.s_addr = (((((192 << 8) | 43) <&l +-----------------------------------+ 12 | 0 | +-----------------------------------+ - + - - sockaddr_in on an Intel system - - + + sockaddr_in on an Intel system + + - On a different system, it might look like this: - + On a different system, it might look like this: - - - - + + + + - - 0 1 2 3 + + 0 1 2 3 +--------+--------+--------+--------+ 0 | 0 | 2 | 0 | 13 | +--------+--------+--------+--------+ @@ -700,21 +698,21 @@ sa.sin_addr.s_addr = (((((192 << 8) | 43) <&l +-----------------------------------+ 12 | 0 | +-----------------------------------+ - + - - sockaddr_in on an MSB system - - + + sockaddr_in on an MSB system + + - And on a PDP it might look different yet. But the + And on a PDP it might look different yet. But the above two are the most common ways in use today. Ordinarily, wanting to write portable code, - programmers pretend that these differences do not - exist. And they get away with it (except when they code in - assembly language). Alas, you cannot get away with it that - easily when coding for sockets. + programmers pretend that these differences do not exist. + And they get away with it (except when they code in + assembly language). Alas, you cannot get away with it + that easily when coding for sockets. Why? @@ -725,37 +723,38 @@ sa.sin_addr.s_addr = (((((192 << 8) | 43) <&l (LSB) first. You might be wondering, So, will - sockets not handle it for me? + sockets not handle it for + me? It will not. While that answer may surprise you at first, remember - that the general sockets interface only understands the - sa_len and sa_family - fields of the sockaddr structure. You - do not have to worry about the byte order there (of - course, on FreeBSD sa_family is only 1 - byte anyway, but many other &unix; systems do not have - sa_len and use 2 bytes for - sa_family, and expect the data in - whatever order is native to the computer). + that the general sockets interface only understands the + sa_len and sa_family + fields of the sockaddr structure. You + do not have to worry about the byte order there (of + course, on FreeBSD sa_family is only 1 + byte anyway, but many other &unix; systems do not have + sa_len and use 2 bytes for + sa_family, and expect the data in + whatever order is native to the computer). But the rest of the data is just - sa_data[14] as far as sockets - goes. Depending on the address - family, sockets just forwards that data to its - destination. + sa_data[14] as far as sockets goes. + Depending on the address family, + sockets just forwards that data to its destination. Indeed, when we enter a port number, it is because we want the other computer to know what service we are asking - for. And, when we are the server, we read the port number + for. And, when we are the server, we read the port number so we know what service the other computer is expecting - from us. Either way, sockets only has to forward the port - number as data. It does not interpret it in any way. + from us. Either way, sockets only has to forward the port + number as data. It does not interpret it in any + way. Similarly, we enter the IP address - to tell everyone on the way where to send our data - to. Sockets, again, only forwards it as data. + to tell everyone on the way where to send our data to. + Sockets, again, only forwards it as data. That is why, we (the programmers, not the sockets) have to distinguish @@ -771,8 +770,8 @@ sa.sin_addr.s_addr = (((((192 << 8) | 43) <&l over IP MSB first. This, we will refer to as the network byte - order, or simply the network - order. + order, or simply the network + order. Now, if we compiled the above code for an Intel based computer, our host byte order would @@ -780,11 +779,11 @@ sa.sin_addr.s_addr = (((((192 << 8) | 43) <&l - - + + - - 0 1 2 3 + + 0 1 2 3 +--------+--------+--------+--------+ 0 | 0 | 2 | 13 | 0 | +--------+--------+--------+--------+ @@ -794,24 +793,24 @@ sa.sin_addr.s_addr = (((((192 << 8) | 43) <&l +-----------------------------------+ 12 | 0 | +-----------------------------------+ - + - - Host byte order on an Intel system - - + + Host byte order on an Intel system + + - But the network byte order - requires that we store the data MSB - first: + But the network byte order + requires that we store the data MSB + first: - - - - + + + + - - 0 1 2 3 + + 0 1 2 3 +--------+--------+--------+--------+ 0 | 0 | 2 | 0 | 13 | +--------+--------+--------+--------+ @@ -821,135 +820,130 @@ sa.sin_addr.s_addr = (((((192 << 8) | 43) <&l +-----------------------------------+ 12 | 0 | +-----------------------------------+ - + - - Network byte order - - + + Network byte order + + - Unfortunately, our host order is + Unfortunately, our host order is the exact opposite of the network - order. + order. - We have several ways of dealing with it. One would be - to reverse the values in our code: - + We have several ways of dealing with it. One would be + to reverse the values in our + code: sa.sin_family = AF_INET; sa.sin_port = 13 << 8; sa.sin_addr.s_addr = (((((18 << 8) | 244) << 8) | 43) << 8) | 192; - This will trick our compiler - into storing the data in the network byte - order. In some cases, this is exactly the way - to do it (e.g., when programming in assembly - language). In most cases, however, it can cause a - problem. + This will trick our compiler into + storing the data in the network byte + order. In some cases, this is exactly the + way to do it (e.g., when programming in assembly + language). In most cases, however, it can cause a + problem. - Suppose, you wrote a sockets-based program in C. You - know it is going to run on a &pentium;, so you enter all - your constants in reverse and force them to the - network byte order. It works - well. + Suppose, you wrote a sockets-based program in C. You + know it is going to run on a &pentium;, so you enter all + your constants in reverse and force them to the + network byte order. It works + well. - Then, some day, your trusted old &pentium; becomes a - rusty old &pentium;. You replace it with a system whose - host order is the same as the - network order. You need to recompile - all your software. All of your software continues to - perform well, except the one program you wrote. + Then, some day, your trusted old &pentium; becomes a + rusty old &pentium;. You replace it with a system whose + host order is the same as the + network order. You need to recompile + all your software. All of your software continues to + perform well, except the one program you wrote. - You have since forgotten that you had forced all of - your constants to the opposite of the host - order. You spend some quality time tearing out - your hair, calling the names of all gods you ever heard - of (and some you made up), hitting your monitor with a - nerf bat, and performing all the other traditional - ceremonies of trying to figure out why something that has - worked so well is suddenly not working at all. + You have since forgotten that you had forced all of + your constants to the opposite of the host + order. You spend some quality time tearing + out your hair, calling the names of all gods you ever + heard of (and some you made up), hitting your monitor with + a nerf bat, and performing all the other traditional + ceremonies of trying to figure out why something that has + worked so well is suddenly not working at all. - Eventually, you figure it out, say a couple of swear - words, and start rewriting your code. + Eventually, you figure it out, say a couple of swear + words, and start rewriting your code. - Luckily, you are not the first one to face the - problem. Someone else has created the &man.htons.3; and - &man.htonl.3; C functions to convert a - short and long - respectively from the host byte - order to the network byte - order, and the &man.ntohs.3; and &man.ntohl.3; - C functions to go the other way. + Luckily, you are not the first one to face the + problem. Someone else has created the &man.htons.3; and + &man.htonl.3; C functions to convert a + short and long + respectively from the host byte order + to the network byte order, and the + &man.ntohs.3; and &man.ntohl.3; C functions to go the + other way. - On MSB-first - systems these functions do nothing. On - LSB-first systems - they convert values to the proper order. + On MSB-first + systems these functions do nothing. On + LSB-first systems + they convert values to the proper order. - So, regardless of what system your software is - compiled on, your data will end up in the correct order - if you use these functions. - - - + So, regardless of what system your software is + compiled on, your data will end up in the correct order if + you use these functions. + *** DIFF OUTPUT TRUNCATED AT 1000 LINES *** From owner-svn-doc-head@freebsd.org Mon Aug 27 05:32:05 2018 Return-Path: Delivered-To: svn-doc-head@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 54AD2108D2AB; Mon, 27 Aug 2018 05:32:05 +0000 (UTC) (envelope-from pi@FreeBSD.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mxrelay.nyi.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 0A7557F505; Mon, 27 Aug 2018 05:32:05 +0000 (UTC) (envelope-from pi@FreeBSD.org) Received: from repo.freebsd.org (repo.freebsd.org [IPv6:2610:1c1:1:6068::e6a:0]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id E15521965F; Mon, 27 Aug 2018 05:32:04 +0000 (UTC) (envelope-from pi@FreeBSD.org) Received: from repo.freebsd.org ([127.0.1.37]) by repo.freebsd.org (8.15.2/8.15.2) with ESMTP id w7R5W44V046781; Mon, 27 Aug 2018 05:32:04 GMT (envelope-from pi@FreeBSD.org) Received: (from pi@localhost) by repo.freebsd.org (8.15.2/8.15.2/Submit) id w7R5W4OE046780; Mon, 27 Aug 2018 05:32:04 GMT (envelope-from pi@FreeBSD.org) Message-Id: <201808270532.w7R5W4OE046780@repo.freebsd.org> X-Authentication-Warning: repo.freebsd.org: pi set sender to pi@FreeBSD.org using -f From: Kurt Jaeger Date: Mon, 27 Aug 2018 05:32:04 +0000 (UTC) To: doc-committers@freebsd.org, svn-doc-all@freebsd.org, svn-doc-head@freebsd.org Subject: svn commit: r52178 - head/en_US.ISO8859-1/htdocs X-SVN-Group: doc-head X-SVN-Commit-Author: pi X-SVN-Commit-Paths: head/en_US.ISO8859-1/htdocs X-SVN-Commit-Revision: 52178 X-SVN-Commit-Repository: doc MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-BeenThere: svn-doc-head@freebsd.org X-Mailman-Version: 2.1.27 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: Mon, 27 Aug 2018 05:32:05 -0000 Author: pi (ports committer) Date: Mon Aug 27 05:32:04 2018 New Revision: 52178 URL: https://svnweb.freebsd.org/changeset/doc/52178 Log: en_US.ISO8859-1/htdocs/administration.xml: Document Wiki Admin Team PR: 204246 Submitted by: pi Reported by: koobs Approved by: remko Modified: head/en_US.ISO8859-1/htdocs/administration.xml Modified: head/en_US.ISO8859-1/htdocs/administration.xml ============================================================================== --- head/en_US.ISO8859-1/htdocs/administration.xml Sun Aug 26 18:34:50 2018 (r52177) +++ head/en_US.ISO8859-1/htdocs/administration.xml Mon Aug 27 05:32:04 2018 (r52178) @@ -74,6 +74,7 @@
  • Postmaster Team
  • Subversion Administrators
  • Webmaster Team
    • +
  • Wiki Admin Team
    • @@ -511,6 +512,21 @@
    • &a.wosch.email;
      • +
    + +

    Wiki Admin Team + <wiki-admin@FreeBSD.org>

    + +

    The FreeBSD Wiki Team is responsible for keeping the FreeBSD + Wiki + site up and running. They also shape the overall design and + content structure.

    + +
      +
    • &a.gavin.email;
      • +
    • &a.linimon.email;
      • +
    • &a.theraven.email;
      • +
    • &a.koobs.email;
    From owner-svn-doc-head@freebsd.org Mon Aug 27 05:32:58 2018 Return-Path: Delivered-To: svn-doc-head@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3F617108D365; Mon, 27 Aug 2018 05:32:58 +0000 (UTC) (envelope-from pi@FreeBSD.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mxrelay.nyi.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E98407F5F0; Mon, 27 Aug 2018 05:32:57 +0000 (UTC) (envelope-from pi@FreeBSD.org) Received: from repo.freebsd.org (repo.freebsd.org [IPv6:2610:1c1:1:6068::e6a:0]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id CAD8819689; Mon, 27 Aug 2018 05:32:57 +0000 (UTC) (envelope-from pi@FreeBSD.org) Received: from repo.freebsd.org ([127.0.1.37]) by repo.freebsd.org (8.15.2/8.15.2) with ESMTP id w7R5Wva5050000; Mon, 27 Aug 2018 05:32:57 GMT (envelope-from pi@FreeBSD.org) Received: (from pi@localhost) by repo.freebsd.org (8.15.2/8.15.2/Submit) id w7R5Wv7S049999; Mon, 27 Aug 2018 05:32:57 GMT (envelope-from pi@FreeBSD.org) Message-Id: <201808270532.w7R5Wv7S049999@repo.freebsd.org> X-Authentication-Warning: repo.freebsd.org: pi set sender to pi@FreeBSD.org using -f From: Kurt Jaeger Date: Mon, 27 Aug 2018 05:32:57 +0000 (UTC) To: doc-committers@freebsd.org, svn-doc-all@freebsd.org, svn-doc-head@freebsd.org Subject: svn commit: r52179 - head/en_US.ISO8859-1/htdocs X-SVN-Group: doc-head X-SVN-Commit-Author: pi X-SVN-Commit-Paths: head/en_US.ISO8859-1/htdocs X-SVN-Commit-Revision: 52179 X-SVN-Commit-Repository: doc MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-BeenThere: svn-doc-head@freebsd.org X-Mailman-Version: 2.1.27 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: Mon, 27 Aug 2018 05:32:58 -0000 Author: pi (ports committer) Date: Mon Aug 27 05:32:57 2018 New Revision: 52179 URL: https://svnweb.freebsd.org/changeset/doc/52179 Log: en_US.ISO8859-1/htdocs/administration.xml: remove skreuzer from donations team Submitted by: skreuzer Approved by: remko (implicit) Modified: head/en_US.ISO8859-1/htdocs/administration.xml Modified: head/en_US.ISO8859-1/htdocs/administration.xml ============================================================================== --- head/en_US.ISO8859-1/htdocs/administration.xml Mon Aug 27 05:32:04 2018 (r52178) +++ head/en_US.ISO8859-1/htdocs/administration.xml Mon Aug 27 05:32:57 2018 (r52179) @@ -197,7 +197,6 @@
  • &a.gahr.email;
  • &a.pgollucci.email;
  • &a.koobs.email;
    • -
  • &a.skreuzer.email;
  • &a.obrien.email;
  • &a.ds.email;
  • &a.rwatson.email;
    • From owner-svn-doc-head@freebsd.org Mon Aug 27 10:30:08 2018 Return-Path: Delivered-To: svn-doc-head@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D89FE1083CB0; Mon, 27 Aug 2018 10:30:08 +0000 (UTC) (envelope-from mat@FreeBSD.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mxrelay.nyi.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 8D73888EB1; Mon, 27 Aug 2018 10:30:08 +0000 (UTC) (envelope-from mat@FreeBSD.org) Received: from repo.freebsd.org (repo.freebsd.org [IPv6:2610:1c1:1:6068::e6a:0]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 67A361C5AD; Mon, 27 Aug 2018 10:30:08 +0000 (UTC) (envelope-from mat@FreeBSD.org) Received: from repo.freebsd.org ([127.0.1.37]) by repo.freebsd.org (8.15.2/8.15.2) with ESMTP id w7RAU8jm099239; Mon, 27 Aug 2018 10:30:08 GMT (envelope-from mat@FreeBSD.org) Received: (from mat@localhost) by repo.freebsd.org (8.15.2/8.15.2/Submit) id w7RAU8Ci099238; Mon, 27 Aug 2018 10:30:08 GMT (envelope-from mat@FreeBSD.org) Message-Id: <201808271030.w7RAU8Ci099238@repo.freebsd.org> X-Authentication-Warning: repo.freebsd.org: mat set sender to mat@FreeBSD.org using -f From: Mathieu Arnold Date: Mon, 27 Aug 2018 10:30:08 +0000 (UTC) To: doc-committers@freebsd.org, svn-doc-all@freebsd.org, svn-doc-head@freebsd.org Subject: svn commit: r52180 - head/en_US.ISO8859-1/books/porters-handbook/makefiles X-SVN-Group: doc-head X-SVN-Commit-Author: mat X-SVN-Commit-Paths: head/en_US.ISO8859-1/books/porters-handbook/makefiles X-SVN-Commit-Revision: 52180 X-SVN-Commit-Repository: doc MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-BeenThere: svn-doc-head@freebsd.org X-Mailman-Version: 2.1.27 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: Mon, 27 Aug 2018 10:30:09 -0000 Author: mat Date: Mon Aug 27 10:30:07 2018 New Revision: 52180 URL: https://svnweb.freebsd.org/changeset/doc/52180 Log: Add a warning about the effect of some permissions. Reviewed by: adamw Differential Revision: https://reviews.freebsd.org/D16624 Modified: head/en_US.ISO8859-1/books/porters-handbook/makefiles/chapter.xml Modified: head/en_US.ISO8859-1/books/porters-handbook/makefiles/chapter.xml ============================================================================== --- head/en_US.ISO8859-1/books/porters-handbook/makefiles/chapter.xml Mon Aug 27 05:32:57 2018 (r52179) +++ head/en_US.ISO8859-1/books/porters-handbook/makefiles/chapter.xml Mon Aug 27 10:30:07 2018 (r52180) @@ -5174,6 +5174,21 @@ LICENSE_FILE= ${WRKSRC}/COPYING     not present, it is considered to be a no-permission. + + Some missing permissions will prevent a port (and all + ports depending on it) from being usable by package + users: + + A port without the auto-accept + permission will never be be built and all the ports + depending on it will be ignored. + + A port without the pkg-mirror + permission will be removed, as well as all the ports + depending on it, after the build and they will ever end up + being distributed. + + Nonstandard License From owner-svn-doc-head@freebsd.org Mon Aug 27 10:51:57 2018 Return-Path: Delivered-To: svn-doc-head@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 484BA108468D; Mon, 27 Aug 2018 10:51:57 +0000 (UTC) (envelope-from rcyu@FreeBSD.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mxrelay.nyi.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id F012A89B46; Mon, 27 Aug 2018 10:51:56 +0000 (UTC) (envelope-from rcyu@FreeBSD.org) Received: from repo.freebsd.org (repo.freebsd.org [IPv6:2610:1c1:1:6068::e6a:0]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id D14F51CA6A; Mon, 27 Aug 2018 10:51:56 +0000 (UTC) (envelope-from rcyu@FreeBSD.org) Received: from repo.freebsd.org ([127.0.1.37]) by repo.freebsd.org (8.15.2/8.15.2) with ESMTP id w7RApu0H011739; Mon, 27 Aug 2018 10:51:56 GMT (envelope-from rcyu@FreeBSD.org) Received: (from rcyu@localhost) by repo.freebsd.org (8.15.2/8.15.2/Submit) id w7RApuI5011738; Mon, 27 Aug 2018 10:51:56 GMT (envelope-from rcyu@FreeBSD.org) Message-Id: <201808271051.w7RApuI5011738@repo.freebsd.org> X-Authentication-Warning: repo.freebsd.org: rcyu set sender to rcyu@FreeBSD.org using -f From: Ruey-Cherng Yu Date: Mon, 27 Aug 2018 10:51:56 +0000 (UTC) To: doc-committers@freebsd.org, svn-doc-all@freebsd.org, svn-doc-head@freebsd.org Subject: svn commit: r52181 - head/zh_TW.UTF-8/share/xml X-SVN-Group: doc-head X-SVN-Commit-Author: rcyu X-SVN-Commit-Paths: head/zh_TW.UTF-8/share/xml X-SVN-Commit-Revision: 52181 X-SVN-Commit-Repository: doc MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-BeenThere: svn-doc-head@freebsd.org X-Mailman-Version: 2.1.27 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: Mon, 27 Aug 2018 10:51:57 -0000 Author: rcyu Date: Mon Aug 27 10:51:56 2018 New Revision: 52181 URL: https://svnweb.freebsd.org/changeset/doc/52181 Log: - Traditional Chinese translation of the latest news item (August 9th) Modified: head/zh_TW.UTF-8/share/xml/news.xml Modified: head/zh_TW.UTF-8/share/xml/news.xml ============================================================================== --- head/zh_TW.UTF-8/share/xml/news.xml Mon Aug 27 10:30:07 2018 (r52180) +++ head/zh_TW.UTF-8/share/xml/news.xml Mon Aug 27 10:51:56 2018 (r52181) @@ -34,6 +34,20 @@ 2018 + 8 + + + 9 + + +

    增加提交權限: + Li-Wen Hsu + (ports, src)

    +     +     +     + + 7 From owner-svn-doc-head@freebsd.org Mon Aug 27 11:36:14 2018 Return-Path: Delivered-To: svn-doc-head@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4DC5210858E4; Mon, 27 Aug 2018 11:36:14 +0000 (UTC) (envelope-from ryusuke@FreeBSD.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mxrelay.nyi.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 04DEC8B7CF; Mon, 27 Aug 2018 11:36:14 +0000 (UTC) (envelope-from ryusuke@FreeBSD.org) Received: from repo.freebsd.org (repo.freebsd.org [IPv6:2610:1c1:1:6068::e6a:0]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id D626E1D15E; Mon, 27 Aug 2018 11:36:13 +0000 (UTC) (envelope-from ryusuke@FreeBSD.org) Received: from repo.freebsd.org ([127.0.1.37]) by repo.freebsd.org (8.15.2/8.15.2) with ESMTP id w7RBaD4f035713; Mon, 27 Aug 2018 11:36:13 GMT (envelope-from ryusuke@FreeBSD.org) Received: (from ryusuke@localhost) by repo.freebsd.org (8.15.2/8.15.2/Submit) id w7RBaDY2035712; Mon, 27 Aug 2018 11:36:13 GMT (envelope-from ryusuke@FreeBSD.org) Message-Id: <201808271136.w7RBaDY2035712@repo.freebsd.org> X-Authentication-Warning: repo.freebsd.org: ryusuke set sender to ryusuke@FreeBSD.org using -f From: Ryusuke SUZUKI Date: Mon, 27 Aug 2018 11:36:13 +0000 (UTC) To: doc-committers@freebsd.org, svn-doc-all@freebsd.org, svn-doc-head@freebsd.org Subject: svn commit: r52182 - head/ja_JP.eucJP/htdocs/java X-SVN-Group: doc-head X-SVN-Commit-Author: ryusuke X-SVN-Commit-Paths: head/ja_JP.eucJP/htdocs/java X-SVN-Commit-Revision: 52182 X-SVN-Commit-Repository: doc MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-BeenThere: svn-doc-head@freebsd.org X-Mailman-Version: 2.1.27 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: Mon, 27 Aug 2018 11:36:14 -0000 Author: ryusuke Date: Mon Aug 27 11:36:13 2018 New Revision: 52182 URL: https://svnweb.freebsd.org/changeset/doc/52182 Log: - Merge the following from the English version: r52094 -> r52174 head/ja_JP.eucJP/htdocs/java/index.xml Modified: head/ja_JP.eucJP/htdocs/java/index.xml Modified: head/ja_JP.eucJP/htdocs/java/index.xml ============================================================================== --- head/ja_JP.eucJP/htdocs/java/index.xml Mon Aug 27 10:51:56 2018 (r52181) +++ head/ja_JP.eucJP/htdocs/java/index.xml Mon Aug 27 11:36:13 2018 (r52182) @@ -5,7 +5,7 @@ - + ]> @@ -17,7 +17,7 @@ - Jump to &java;

    Java ꤹ

    From owner-svn-doc-head@freebsd.org Mon Aug 27 12:29:47 2018 Return-Path: Delivered-To: svn-doc-head@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 588BC108815E; Mon, 27 Aug 2018 12:29:47 +0000 (UTC) (envelope-from ryusuke@FreeBSD.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mxrelay.nyi.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 075958DD01; Mon, 27 Aug 2018 12:29:47 +0000 (UTC) (envelope-from ryusuke@FreeBSD.org) Received: from repo.freebsd.org (repo.freebsd.org [IPv6:2610:1c1:1:6068::e6a:0]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id BA1E71D983; Mon, 27 Aug 2018 12:29:46 +0000 (UTC) (envelope-from ryusuke@FreeBSD.org) Received: from repo.freebsd.org ([127.0.1.37]) by repo.freebsd.org (8.15.2/8.15.2) with ESMTP id w7RCTk3Y062082; Mon, 27 Aug 2018 12:29:46 GMT (envelope-from ryusuke@FreeBSD.org) Received: (from ryusuke@localhost) by repo.freebsd.org (8.15.2/8.15.2/Submit) id w7RCTk7i062080; Mon, 27 Aug 2018 12:29:46 GMT (envelope-from ryusuke@FreeBSD.org) Message-Id: <201808271229.w7RCTk7i062080@repo.freebsd.org> X-Authentication-Warning: repo.freebsd.org: ryusuke set sender to ryusuke@FreeBSD.org using -f From: Ryusuke SUZUKI Date: Mon, 27 Aug 2018 12:29:46 +0000 (UTC) To: doc-committers@freebsd.org, svn-doc-all@freebsd.org, svn-doc-head@freebsd.org Subject: svn commit: r52183 - in head/ja_JP.eucJP: htdocs share/xml X-SVN-Group: doc-head X-SVN-Commit-Author: ryusuke X-SVN-Commit-Paths: in head/ja_JP.eucJP: htdocs share/xml X-SVN-Commit-Revision: 52183 X-SVN-Commit-Repository: doc MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-BeenThere: svn-doc-head@freebsd.org X-Mailman-Version: 2.1.27 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: Mon, 27 Aug 2018 12:29:47 -0000 Author: ryusuke Date: Mon Aug 27 12:29:46 2018 New Revision: 52183 URL: https://svnweb.freebsd.org/changeset/doc/52183 Log: - Merge the following from the English version: r51914 -> r52172 head/ja_JP.eucJP/htdocs/where.xml r51848 -> r52172 head/ja_JP.eucJP/share/xml/release.l10n.ent Modified: head/ja_JP.eucJP/htdocs/where.xml head/ja_JP.eucJP/share/xml/release.l10n.ent Modified: head/ja_JP.eucJP/htdocs/where.xml ============================================================================== --- head/ja_JP.eucJP/htdocs/where.xml Mon Aug 27 11:36:13 2018 (r52182) +++ head/ja_JP.eucJP/htdocs/where.xml Mon Aug 27 12:29:46 2018 (r52183) @@ -6,7 +6,7 @@ ]> - + @@ -59,7 +59,7 @@

    &os; ϡǥץȤ׾򽸤Ƥޤ󤬡 ׾ѽפǤΤǡ ҤȤ sysutils/bsdstats + href="https://www.freshports.org/sysutils/bsdstats/">sysutils/bsdstats package 򥤥󥹥ȡ뤷Ƥ package ϡϡɥӥեȥ׾򽸤ᡢ ȯԤɤ˽椷ƳȯԤ٤Ƥ󶡤ޤ @@ -278,8 +278,8 @@

  • i386
  • powerpc
  • powerpc64
    • +
  • powerpcspe
  • sparc64
    • -
  • arm
  • armv6
  • armv7
  • aarch64
    • @@ -299,9 +299,10 @@
  • CUBIEBOARD
  • CUBIEBOARD2
  • CUBOX/HUMMINGBOARD
    • -
  • GUMSTIX
    • +
  • GENERICSD
  • PANDABOARD
  • PINE64
    • +
  • PINE64-LTS
  • RPI-B
  • RPI2
  • RPI3
    • @@ -337,7 +338,6 @@
  • powerpc
  • powerpc64
  • sparc64
    • -
  • arm
  • armv6
  • aarch64
    • @@ -356,7 +356,6 @@
  • CUBIEBOARD
  • CUBIEBOARD2
  • CUBOX/HUMMINGBOARD
    • -
  • GUMSTIX
  • PANDABOARD
  • RPI2
  • RPI-B
    • @@ -393,7 +392,6 @@
  • powerpc
  • powerpc64
  • sparc64
    • -
  • arm
  • armv6
    • @@ -407,7 +405,6 @@ @@ -107,16 +108,19 @@ @@ -127,8 +131,8 @@ 󥹥ȡ륬
  • TODO ꥹ
    • - ?>
  • ̾ѥå
    • + ?>
  • ꡼Ρ
    • From owner-svn-doc-head@freebsd.org Mon Aug 27 12:58:54 2018 Return-Path: Delivered-To: svn-doc-head@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 61C161088A67; Mon, 27 Aug 2018 12:58:54 +0000 (UTC) (envelope-from ryusuke@FreeBSD.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mxrelay.nyi.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 13C188EB57; Mon, 27 Aug 2018 12:58:54 +0000 (UTC) (envelope-from ryusuke@FreeBSD.org) Received: from repo.freebsd.org (repo.freebsd.org [IPv6:2610:1c1:1:6068::e6a:0]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id E61E01DE50; Mon, 27 Aug 2018 12:58:53 +0000 (UTC) (envelope-from ryusuke@FreeBSD.org) Received: from repo.freebsd.org ([127.0.1.37]) by repo.freebsd.org (8.15.2/8.15.2) with ESMTP id w7RCwrT0077419; Mon, 27 Aug 2018 12:58:53 GMT (envelope-from ryusuke@FreeBSD.org) Received: (from ryusuke@localhost) by repo.freebsd.org (8.15.2/8.15.2/Submit) id w7RCwrQn077418; Mon, 27 Aug 2018 12:58:53 GMT (envelope-from ryusuke@FreeBSD.org) Message-Id: <201808271258.w7RCwrQn077418@repo.freebsd.org> X-Authentication-Warning: repo.freebsd.org: ryusuke set sender to ryusuke@FreeBSD.org using -f From: Ryusuke SUZUKI Date: Mon, 27 Aug 2018 12:58:53 +0000 (UTC) To: doc-committers@freebsd.org, svn-doc-all@freebsd.org, svn-doc-head@freebsd.org Subject: svn commit: r52184 - head/ja_JP.eucJP/books/handbook/ports X-SVN-Group: doc-head X-SVN-Commit-Author: ryusuke X-SVN-Commit-Paths: head/ja_JP.eucJP/books/handbook/ports X-SVN-Commit-Revision: 52184 X-SVN-Commit-Repository: doc MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-BeenThere: svn-doc-head@freebsd.org X-Mailman-Version: 2.1.27 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: Mon, 27 Aug 2018 12:58:54 -0000 Author: ryusuke Date: Mon Aug 27 12:58:53 2018 New Revision: 52184 URL: https://svnweb.freebsd.org/changeset/doc/52184 Log: - Merge the following from the English version: r50603 -> r51348 head/ja_JP.eucJP/books/handbook/ports/chapter.xml Modified: head/ja_JP.eucJP/books/handbook/ports/chapter.xml Modified: head/ja_JP.eucJP/books/handbook/ports/chapter.xml ============================================================================== --- head/ja_JP.eucJP/books/handbook/ports/chapter.xml Mon Aug 27 12:29:46 2018 (r52183) +++ head/ja_JP.eucJP/books/handbook/ports/chapter.xml Mon Aug 27 12:58:53 2018 (r52184) @@ -3,7 +3,7 @@ The FreeBSD Documentation Project The FreeBSD Japanese Documentation Project - Original revision: r50603 + Original revision: r51348 $FreeBSD$ --> ץꥱ򥤥󥹥ȡ뤹ˡ Υץꥱ˴Ϣƥ꤬ʤȤ + xlink:href="https://vuxml.freebsd.org/"> dzǧ뤫pkg audit -F Ϥơ 󥹥ȡ뤵Ƥ륢ץꥱ˴ΤȼʤȤǧƤ @@ -226,7 +226,7 @@ &os; ֥Ȥϡ Ѳǽʤ٤ƤΥץꥱκǿΰ򡢸Ǥ - http://www.FreeBSD.org/ja/ports/ + https://www.FreeBSD.org/ja/ports/ ˤƸƤޤ ports ϥץꥱ̾䡢եȥΥƥǸޤ @@ -447,7 +447,7 @@ Info: Lists information about open files (similar to Υ֡ȥȥåץץϡ٤Ƥ &os; С󤪤ӥƥбƤ櫓ǤϤޤ бƤϡ - + dzǧ뤳ȤǤޤ бƤʤˤϡ Ports Collection ޤϥХʥ package @@ -957,7 +957,7 @@ Deinstalling ca_root_nss-3.15.1_1... done ɥѡƥΥեȥ򥤥󥹥ȡ뤹ȡ ƥȼǽޤ port ˴Ϣƥ꤬ʤȤ򡢤ޤ - + dzǧƤޤϡ port 򥤥󥹥ȡ뤹ˡ pkg audit -F ¹ԤƤ From owner-svn-doc-head@freebsd.org Tue Aug 28 03:24:46 2018 Return-Path: Delivered-To: svn-doc-head@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 1242310A0309; Tue, 28 Aug 2018 03:24:46 +0000 (UTC) (envelope-from dbaio@FreeBSD.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mxrelay.nyi.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id BAB1570178; Tue, 28 Aug 2018 03:24:45 +0000 (UTC) (envelope-from dbaio@FreeBSD.org) Received: from repo.freebsd.org (repo.freebsd.org [IPv6:2610:1c1:1:6068::e6a:0]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 9B09426FDF; Tue, 28 Aug 2018 03:24:45 +0000 (UTC) (envelope-from dbaio@FreeBSD.org) Received: from repo.freebsd.org ([127.0.1.37]) by repo.freebsd.org (8.15.2/8.15.2) with ESMTP id w7S3OjUl030963; Tue, 28 Aug 2018 03:24:45 GMT (envelope-from dbaio@FreeBSD.org) Received: (from dbaio@localhost) by repo.freebsd.org (8.15.2/8.15.2/Submit) id w7S3OjDq030961; Tue, 28 Aug 2018 03:24:45 GMT (envelope-from dbaio@FreeBSD.org) Message-Id: <201808280324.w7S3OjDq030961@repo.freebsd.org> X-Authentication-Warning: repo.freebsd.org: dbaio set sender to dbaio@FreeBSD.org using -f From: "Danilo G. Baio" Date: Tue, 28 Aug 2018 03:24:45 +0000 (UTC) To: doc-committers@freebsd.org, svn-doc-all@freebsd.org, svn-doc-head@freebsd.org Subject: svn commit: r52185 - head/pt_BR.ISO8859-1/articles/building-products X-SVN-Group: doc-head X-SVN-Commit-Author: dbaio X-SVN-Commit-Paths: head/pt_BR.ISO8859-1/articles/building-products X-SVN-Commit-Revision: 52185 X-SVN-Commit-Repository: doc MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-BeenThere: svn-doc-head@freebsd.org X-Mailman-Version: 2.1.27 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, 28 Aug 2018 03:24:46 -0000 Author: dbaio (ports committer) Date: Tue Aug 28 03:24:45 2018 New Revision: 52185 URL: https://svnweb.freebsd.org/changeset/doc/52185 Log: pt_BR.ISO8859-1/articles/building-products: Convert to .po Changes in the Makefile to follow English document. Reviewed by: bcr, ebrandi, wblock Approved by: bcr, wblock Differential Revision: https://reviews.freebsd.org/D15796 Added: head/pt_BR.ISO8859-1/articles/building-products/pt_BR.po (contents, props changed) Modified: head/pt_BR.ISO8859-1/articles/building-products/Makefile head/pt_BR.ISO8859-1/articles/building-products/article.xml (contents, props changed) Modified: head/pt_BR.ISO8859-1/articles/building-products/Makefile ============================================================================== --- head/pt_BR.ISO8859-1/articles/building-products/Makefile Mon Aug 27 12:58:53 2018 (r52184) +++ head/pt_BR.ISO8859-1/articles/building-products/Makefile Tue Aug 28 03:24:45 2018 (r52185) @@ -3,14 +3,11 @@ # # $FreeBSD$ # -# Original revision: r38826 -# # Article: Building products using FreeBSD DOC?= article -FORMATS?= html html-split -WITH_ARTICLE_TOC?= YES +FORMATS?= html INSTALL_COMPRESSED?= gz INSTALL_ONLY_COMPRESSED?= Modified: head/pt_BR.ISO8859-1/articles/building-products/article.xml ============================================================================== --- head/pt_BR.ISO8859-1/articles/building-products/article.xml Mon Aug 27 12:58:53 2018 (r52184) +++ head/pt_BR.ISO8859-1/articles/building-products/article.xml Tue Aug 28 03:24:45 2018 (r52185) @@ -1,25 +1,15 @@ - - - -
    + + +
    Construindo Produtos com o FreeBSD - JosephKoshy - The FreeBSD Project -
    jkoshy@FreeBSD.org
    -     + JosephKoshy The FreeBSD Project
    jkoshy@FreeBSD.org
         - &tm-attrib.freebsd; - &tm-attrib.general; + FreeBSD is a registered trademark of the FreeBSD Foundation. + Many of the designations used by manufacturers and sellers to distinguish their products are claimed as trademarks. Where those designations appear in this document, and the FreeBSD Project was aware of the trademark claim, the designations have been followed by the ™ or the ® symbol. $FreeBSD$ @@ -27,299 +17,139 @@ $FreeBSD$ - Sumrio + Sumário - O projeto FreeBSD um projeto voluntrio e colaborativo - de mbito mundial, o qual desenvolve um sistema operacional de - alta qualidade, capaz de ser utilizado em diferentes - arquiteturas computacionais. O projeto FreeBSD distribui o - cdigo fonte do seu produto sob uma licena liberal, com a - inteno de incentivar o uso de seu cdigo. Colaborar com o - projeto FreeBSD pode ajudar sua empresa a reduzir o tempo - necessrio para colocar um produto no mercado, a reduzir - seus custos de engenharia e a melhorar qualidade de seus - produtos. - - Este artigo analisa as questes envolvidas no uso do - cdigo do FreeBSD em appliances e softwares. Ele tambm - destaca as caractersticas do FreeBSD, que o tornam uma - excelente base para o desenvolvimento de produtos. O artigo - conclui sugerindo um conjunto das melhores - prticas de organizaes que colaboram com o projeto - FreeBSD. + O projeto FreeBSD é um projeto voluntário e colaborativo de âmbito mundial, o qual desenvolve um sistema operacional de alta qualidade, capaz de ser utilizado em diferentes arquiteturas computacionais. O projeto FreeBSD distribui o código fonte do seu produto sob uma licença liberal, com a intenção de incentivar o uso de seu código. Colaborar com o projeto FreeBSD pode ajudar sua empresa a reduzir o tempo necessário para colocar um produto no mercado, a reduzir seus custos de engenharia e a melhorar qualidade de seus produtos. + + Este artigo analisa as questões envolvidas no uso do código do FreeBSD em appliances e softwares. Ele também destaca as características do FreeBSD, que o tornam uma excelente base para o desenvolvimento de produtos. O artigo conclui sugerindo um conjunto das melhores práticas de organizações que colaboram com o projeto FreeBSD.     - Introduo + Introdução - Atualmente o FreeBSD bem conhecido como um sistema - operacional de alto desempenho para servidores. Ele est - instalado em milhes de servidores web e em outros hosts - conectados diretamente a internet em todo o mundo. O cdigo - do FreeBSD tambm parte integrante de muitos produtos, que - vo desde aparelhos como roteadores de rede, firewalls e - dispositivos de armazenamento, at computadores pessoais. - Partes do FreeBSD tambm tm sido utilizadas em softwares - comerciais (consulte ). + Atualmente o FreeBSD é bem conhecido como um sistema operacional de alto desempenho para servidores. Ele está instalado em milhões de servidores web e em outros hosts conectados diretamente a internet em todo o mundo. O código do FreeBSD também é parte integrante de muitos produtos, que vão desde aparelhos como roteadores de rede, firewalls e dispositivos de armazenamento, até computadores pessoais. Partes do FreeBSD também têm sido utilizadas em softwares comerciais (consulte ). - Neste artigo, vamos olhar para o Projeto FreeBSD como um recurso de - engenharia de software — como um conjunto de blocos de - construo e de processos os quais voc pode utilizar para - construir produtos. + Neste artigo, vamos olhar para o projeto FreeBSD como um recurso de engenharia de software —como um conjunto de blocos de construção e de processos os quais você pode utilizar para construir produtos. - Embora o cdigo fonte do FreeBSD seja distribudo - gratuitamente ao pblico, para desfrutar plenamente dos - benefcios do trabalho do projeto, as organizaes precisam - colaborar com o mesmo. Nas sees - subsequentes do presente artigo discutiremos formas eficazes de - colaborar com o projeto, bem como os perigos que precisam ser - evitados ao faz-lo. + Embora o código fonte do FreeBSD seja distribuído gratuitamente ao público, para desfrutar plenamente dos benefícios do trabalho do projeto, as organizações precisam colaborar com o mesmo. Nas seções subsequentes do presente artigo discutiremos formas eficazes de colaborar com o projeto, bem como os perigos que precisam ser evitados ao fazê-lo. - Advertncia ao Leitor - - O autor considera que as caractersticas do projeto - FreeBSD mencionadas neste artigo eram substancialmente - verdadeiras no momento em que o artigo foi concebido e - escrito (2005). No entanto, o leitor deve ter em mente que - as prticas e processos utilizados por comunidades de cdigo - aberto podem mudar ao longo do tempo, e que portanto as - informaes deste artigo devem ser consideradas apenas como - indicativas e no como verdades absolutas. + Aviso ao Leitor + O autor considera que as características do projeto FreeBSD mencionadas neste artigo eram substancialmente verdadeiras no momento em que o artigo foi concebido e escrito (2005). No entanto, o leitor deve ter em mente que as práticas e processos utilizados por comunidades de código aberto podem mudar ao longo do tempo, e que portanto as informações deste artigo devem ser consideradas apenas como indicativas e não como verdades absolutas. - Pblico Alvo - - Este documento tem como pblico alvo os seguintes grupos - de pessoas: - + Público Alvo + Este documento tem como público alvo os seguintes grupos de pessoas: - Tomadores de deciso em empresas que estejam em - busca de meios para melhorar a qualidade de seus produtos, - de reduzir o tempo necessrio para lan-los no mercado e - de reduzir seus custos de engenharia no longo - prazo. + Tomadores de decisão em empresas que estejam em busca de meios para melhorar a qualidade de seus produtos, de reduzir o tempo necessário para lançá-los no mercado e de reduzir seus custos de engenharia no longo prazo. - Consultores de tecnologia procurando as melhores - prticas para alavancar projetos de cdigo - aberto. + Consultores de tecnologia procurando as melhores práticas para alavancar projetos de código aberto. - Observadores da indstria interessados em - compreender a dinmica dos projetos de cdigo - aberto. - + Observadores da indústria interessados em compreender a dinâmica dos projetos de código aberto. - Desenvolvedores de software que utilizam o FreeBSD - e que buscam formas de contribuir com o projeto. + Desenvolvedores de software que utilizam o FreeBSD e que buscam formas de contribuir com o projeto. Objetivos do artigo - Aps a leitura deste artigo, voc deve ter: + Após a leitura deste artigo, você deve ter: - Uma melhor compreenso dos objetivos do Projeto - FreeBSD e de sua estrutura organizacional. + Uma melhor compreensão dos objetivos do Projeto FreeBSD e de sua estrutura organizacional. - Uma viso geral das tecnologias disponveis no - projeto. + Uma visão geral das tecnologias disponíveis no projeto. - Uma melhor compreenso do modelo de - desenvolvimento adotado pelo Projeto FreeBSD e dos - processos de engenharia envolvidos no lanamento de uma - nova verso do sistema. + Uma melhor compreensão do modelo de desenvolvimento adotado pelo Projeto FreeBSD e dos processos de engenharia envolvidos no lançamento de uma nova versão do sistema. - Uma compreenso de como os processos convencionais - de desenvolvimento de software em uma empresa diferem dos - processos utilizados no projeto FreeBSD. + Consciência dos canais de comunicação utilizados pelo projeto e do nível de transparência que você pode esperar. - Conscincia dos canais de comunicao utilizados - pelo projeto e do nvel de transparncia que voc pode - esperar. + Consciência das melhores formas de se trabalhar com o projeto—a melhor forma de reduzir os custos de engenharia, de reduzir o tempo necessário para levar seu produto ao mercado, de gerir vulnerabilidades de segurança, e de preservar a compatibilidade futura com o seu produto a medida que o Projeto FreeBSD evolui. - - Conscincia das melhores formas de se trabalhar - com o projeto — a melhor forma de reduzir os custos - de engenharia, de reduzir o tempo necessrio para levar - seu produto ao mercado, de gerir vulnerabilidades de - segurana, e de preservar a compatibilidade futura com o - seu produto a medida que o Projeto FreeBSD - evolui. - Estrutura do Artigo - O restante deste artigo est estruturado da seguinte - forma: + O restante deste artigo está estruturado da seguinte forma: - A apresenta o - projeto FreeBSD, explora sua estrutura organizacional, as - principais tecnologias e processos de engenharia - envolvidos no lanamento de uma nova verso do - sistema. + A apresenta o projeto FreeBSD, explora sua estrutura organizacional, as principais tecnologias e processos de engenharia envolvidos no lançamento de uma nova versão do sistema. - A - descreve formas de colaborar com o Projeto FreeBSD. Esta - seo tambm aborda as armadilhas que so geralmente - encontradas por empresas que trabalham com projetos - voluntrios como o FreeBSD. + A descreve formas de colaborar com o Projeto FreeBSD. Esta seção também aborda as armadilhas que são geralmente encontradas por empresas que trabalham com projetos voluntários como o FreeBSD. - A conclui o - artigo. + A conclui o artigo. - O FreeBSD como um conjunto de blocos de construo + O FreeBSD como um conjunto de blocos de construção - O FreeBSD fornece uma excelente base sobre a qual podemos - construir produtos: - + O FreeBSD fornece uma excelente base sobre a qual podemos construir produtos: + - O cdigo fonte do FreeBSD distribudo sob uma - licena BSD liberal, o que facilita sua adoo em produtos - comerciais com um mnimo de preocupaes. - Mon2005 + O código fonte do FreeBSD é distribuído sob uma licença BSD liberal, o que facilita sua adoção em produtos comerciais Mon2005 com um mínimo de preocupações. - O Projeto FreeBSD possui excelentes prticas de - engenharia as quais podem ser aproveitadas. + O Projeto FreeBSD possui excelentes práticas de engenharia as quais podem ser aproveitadas. - O projeto oferece uma transparncia excepcional em - seu funcionamento, permitindo que as empresas que utilizam o - seu cdigo se planejem de forma eficaz para o - futuro. + O projeto oferece uma transparência excepcional em seu funcionamento, permitindo que as empresas que utilizam o seu código se planejem de forma eficaz para o futuro. - A cultura do projeto FreeBSD, herdada do Grupo de - Pesquisa de Cincias da Computao da Universidade da - Califrnia em Berkeley McKu1999-1, - fomenta trabalhos de alta qualidade. Algumas - funcionalidades do FreeBSD definem o estado da - arte. + A cultura do projeto FreeBSD, herdada do Grupo de Pesquisa de Ciências da Computação da Universidade da Califórnia em Berkeley McKu1999-1, fomenta trabalhos de alta qualidade. Algumas funcionalidades do FreeBSD definem o estado da arte. - O GoldGab2005 analisa em maior - profundidade os motivos comerciais para se utilizar cdigo fonte - aberto. Para as organizaes, os benefcios do uso de - componentes do FreeBSD em seus produtos incluem a reduo do - tempo necessrio para lanar novos produtos no mercado, - menores custos e menores riscos de desenvolvimento. - + O GoldGab2005 analisa em maior profundidade os motivos comerciais para se utilizar código fonte aberto. Para as organizações, os benefícios do uso de componentes do FreeBSD em seus produtos incluem a redução do tempo necessário para lançar novos produtos no mercado, menores custos e menores riscos de desenvolvimento. + Construindo com o FreeBSD - Aqui esto alguns exemplos de como as empresas esto - utilizando o FreeBSD: + Aqui estão alguns exemplos de como as empresas estão utilizando o FreeBSD: - Como um provedor (upstream - source) de cdigos testados para - bibliotecas e utilitrios. - - Sendo o downstream - do projeto, as organizaes se aproveitam das novas - funcionalidades, das correes de bugs e dos testes que o - cdigo fonte do projeto FreeBSD recebe. + Como um provedor (upstream source) de códigos testados para bibliotecas e utilitários. + Sendo o downstream do projeto, as organizações se aproveitam das novas funcionalidades, das correções de bugs e dos testes que o código fonte do projeto FreeBSD recebe. - Como sistema operacional integrado (por exemplo, em - um roteador OEM e ou em um dispositivo de firewall). - Neste modelo, as empresas utilizam uma verso customizada - do kernel e do conjunto de aplicativos do FreeBSD, - juntamente com uma camada proprietria de gesto para os - seus dispositivos. Os fabricantes de equipamentos - originais (OEMs) se beneficiam da adio por parte do - FreeBSD de suporte a novos componentes de hardware, bem - como se beneficia dos testes que o sistema base - recebe. - - O FreeBSD distribudo com um ambiente de - desenvolvimento auto-hospedado o qual permite a fcil - criao de tais configuraes. + Como sistema operacional integrado (por exemplo, em um roteador OEM e ou em um dispositivo de firewall). Neste modelo, as empresas utilizam uma versão customizada do kernel e do conjunto de aplicativos do FreeBSD, juntamente com uma camada proprietária de gestão para os seus dispositivos. Os fabricantes de equipamentos originais (OEMs) se beneficiam da adição por parte do FreeBSD de suporte a novos componentes de hardware, bem como se beneficia dos testes que o sistema base recebe. + O FreeBSD é distribuído com um ambiente de desenvolvimento auto-hospedado o qual permite a fácil criação de tais configurações. - Como um ambiente Unix compatvel para as funes de - gerenciamento em dispositivos de armazenamento high-end e - em dispositivos de rede, executando em uma lmina - separada. - - O FreeBSD fornece ferramentas para a criao de - imagens do sistema operacional dedicadas a executar uma - funo especfica. Sua implementao da API unix BSD - madura e testada. O FreeBSD tambm pode proporcionar um - ambiente de desenvolvimento cruzado estvel para os outros - componentes de dispositivos topo de linha. + Como um ambiente Unix compatível para as funções de gerenciamento em dispositivos de armazenamento high-end e em dispositivos de rede, executando em uma lâmina separada blade. + O FreeBSD fornece ferramentas para a criação de imagens do sistema operacional dedicadas a executar uma função específica. Sua implementação da API unix BSD é madura e testada. O FreeBSD também pode proporcionar um ambiente de desenvolvimento cruzado estável para os outros componentes de dispositivos topo de linha. - Como um veculo para obter suporte e testes - amplos de uma equipe mundial de desenvolvedores para a sua - propriedade intelectual - no-crtica. - - Neste modelo, as organizaes contribuem com - frameworks de infra-estrutura teis ao projeto FreeBSD - (por exemplo, veja o &man.netgraph.3;). A ampla - exposio que o cdigo obtm ajuda na rpida - identificao de bugs e de problemas de desempenho. O - envolvimento de desenvolvedores de alta qualidade tambm - resulta no desenvolvimento de extenses teis para a - infra-estrutura do sistema, e das quais a empresa que est - contribuindo com o projeto tambm se beneficia. + Como um veículo para obter suporte e testes amplos de uma equipe mundial de desenvolvedores para a sua propriedade intelectual não-crítica. + Neste modelo, as organizações contribuem com frameworks de infra-estrutura úteis ao projeto FreeBSD (por exemplo, veja o netgraph3). A ampla exposição que o código obtém ajuda na rápida identificação de bugs e de problemas de desempenho. O envolvimento de desenvolvedores de alta qualidade também resulta no desenvolvimento de extensões úteis para a infra-estrutura do sistema, e das quais a empresa que está contribuindo com o projeto também se beneficia. - Como um ambiente de desenvolvimento apoiando - desenvolvimento cruzado para sistemas operacionais - embarcados como RTEMS e o eCOS. - - Existem muitos ambientes de desenvolvimento - completos na forte coleo de mais de &os.numports; - aplicativos portados e empacotados para o - FreeBSD. + Como um ambiente de desenvolvimento apoiando desenvolvimento cruzado para sistemas operacionais embarcados como RTEMS e o eCOS. + Existem muitos ambientes de desenvolvimento completos na forte coleção de mais de 24,000 aplicativos portados e empacotados para o FreeBSD. - Como forma de suportar uma API estilo Unix em um - sistema operacional que de outro modo seria proprietrio, - aumentando a sua palatabilidade para os desenvolvedores de - aplicativos. - - Aqui as partes do kernel do FreeBSD e as aplicaes - so portadas para serem executadas - juntamente com outras tarefas no sistema operacional - proprietrio. A disponibilidade de uma implementao - estvel e bem testada da API Unix - pode reduzir o esforo necessrio para portar aplicaes - populares para um sistema operacional proprietrio. Como - o FreeBSD distribudo acompanhado de uma documentao de - alta qualidade sobre a sua estrutura interna, e possui - processos eficazes de engenharia para gerenciamento de - vulnerabilidades e para lanamento de novas verses, os - custos para mant-lo atualizado so baixos. + Como forma de suportar uma API estilo Unix em um sistema operacional que de outro modo seria proprietário, aumentando a sua palatabilidade para os desenvolvedores de aplicativos. + Aqui as partes do kernel do FreeBSD e as aplicações são portadas para serem executadas juntamente com outras tarefas no sistema operacional proprietário. A disponibilidade de uma implementação estável e bem testada da API Unix pode reduzir o esforço necessário para portar aplicações populares para um sistema operacional proprietário. Como o FreeBSD é distribuído acompanhado de uma documentação de alta qualidade sobre a sua estrutura interna, e possui processos eficazes de engenharia para gerenciamento de vulnerabilidades e para lançamento de novas versões, os custos para mantê-lo atualizado são baixos. @@ -327,119 +157,49 @@ Tecnologias - Existe um grande nmero de tecnologias suportadas pelo - projeto FreeBSD. Abaixo voc encontra uma lista com alguma - delas: + Existe um grande número de tecnologias suportadas pelo projeto FreeBSD. Abaixo você encontra uma lista com alguma delas: - Um sistema completo que pode compilar a si mesmo - de forma cruzada para as seguintes arquiteturas: alpha - (at o &os; verso 6.X), amd64, ia64, i386, sparc64, - powerpc (veja &man.build.7;). + Um sistema completo que pode compilar a si mesmo para muitas arquiteturas: - Suporte para as seguintes tecnologias, protocolos e - padres: - ATA, ATAPI, - ATM, Bluetooth, - CAM, CardBus, - DHCP, DNS, - EISA, - Ethernet, FDDI, - Fibre Channel, GPIB, IEEE 1394, IPv4, - IPv6, IPSEC, - IPX, ISDN, - MAC, NIS, - NFS, OpenSSH, OPIE, - PAM, PCI, - PCMCIA, POSIX, - PnP, RAID, - RPC, SATA, - SCSI, SMB, - TCP, USB, - VESA, VLAN, - VLB, - WebNFS. + Um kernel modular capaz de multiprocessamento simétrico, com módulos de kernel carregáveis e um sistema de configuração flexível e fácil de usar. - Um kernel modular capaz de multiprocessamento - simtrico, com mdulos de kernel carregveis e um - sistema de configurao flexvel e fcil de - usar. + Suporta a emulação de binários do Linux e do SVR4 com velocidades próximas as que você obtém executando os aplicativos de forma nativa. Suporte para os binários dos drivers de rede do Windows (NDIS). - Suporta a emulao de binrios do Linux e do SVR4 - com velocidades prximas as que voc obtm executando os - aplicativos de forma nativa. Suporte para os binrios dos - drivers de rede do Windows - (NDIS). + Bibliotecas para muitas tarefas de programação: arquivos, suporte a FTP e HTTP, suporte a threads, além de um ambiente completo de programação POSIX. - Bibliotecas para muitas tarefas de programao: - arquivos, suporte a FTP e HTTP, suporte a threads, alm - de um ambiente completo de programao - POSIX like. + Funcionalidades avançadas de segurança: Controle de Acesso Obrigatório (mac9), jails (jail2), ACLs, e suporte no kernel a dispositivos de criptografia. - Funcionalidades avanadas de segurana: Controle - de Acesso Obrigatrio (&man.mac.9;), jails (&man.jail.2;), - ACLs,e suporte no kernel a dispositivos - de criptografia. + Funcionalidades avançadas de rede: firewalls, gerenciamento de QoS, rede TCP/IP de alta performance com suporte a muitos recursos avançados. + O framework Netgraph (netgraph4) presente no kernel do FreeBSD, permite que os módulos de rede possam ser conectados entre si de formas flexíveis. - Funcionalidades avanadas de rede: firewalls, - gerenciamento de QoS, rede TCP/IP de alta performance com - suporte a muitos recursos avanados. - O framework Netgraph (&man.netgraph.4;) presente no - kernel do FreeBSD, permite que os mdulos de rede possam - ser conectados entre si de formas flexveis. + Suporte para tecnologias avançadas de armazenamento Fibre Channel, SCSI, RAID por software e hardware, ATA e SATA. + O FreeBSD suporta um grande numero de sistemas de arquivos, e o seu sistema de arquivos nativo UFS2 suporta soft updates, snapshots e sistemas de arquivos de tamanho muito grandes (até 16 TB por sistema de arquivos) McKu1999. + O framework GEOM GEOM (geom4) presente no kernel do FreeBSD permite que módulos de armazenamento sejam compostos de forma flexível. - Suporte para tecnologias avanadas de armazenamento - Fibre Channel, SCSI, RAID por - software e hardware, ATA e - SATA. - O FreeBSD suporta um grande numero de sistemas de - arquivos, e o seu sistema de arquivos nativo UFS2 suporta - soft updates, - snapshots e sistemas de arquivos de - tamanho muito grandes (at 16 TB por sistema de arquivos) - McKu1999. - O framework GEOM (&man.geom.4;) - presente no kernel do FreeBSD permite que mdulos de - armazenamento sejam compostos de forma flexvel. + Mais de 24,000 aplicativos portados, tanto comerciais quanto de código aberto, gerenciados através da coleção de ports do FreeBSD. - - Mais de &os.numports; aplicativos portados, tanto - comerciais quanto de cdigo aberto, gerenciados atravs da - coleo de ports do FreeBSD. - Estrutura Organizacional - A estrutura organizacional do FreeBSD no - hierrquica - - Existem basicamente dois tipos de colaboradores no projeto - FreeBSD, os usurios em geral e os desenvolvedores com acesso - de escrita (conhecidos como committers - no jargo) ao repositrio de cdigo fonte. - - Existem muitos milhares de colaboradores no primeiro - grupo, a grande maioria das contribuies para o FreeBSD vm - de indivduos desse grupo; A permisso de - commit (acesso de escrita) no repositrio - concedida a pessoas que contribuem de forma consistente para o - projeto. O direito de commit vem - acompanhado de responsabilidades adicionais, e para facilitar - o aprendizado das mesmas, um mentor atribudo a todos os - novos committers. + A estrutura organizacional do FreeBSD não é hierárquica. + Existem basicamente dois tipos de colaboradores no projeto FreeBSD, os usuários em geral e os desenvolvedores com acesso de escrita (conhecidos como committers no jargão) ao repositório de código fonte. + + Existem muitos milhares de colaboradores no primeiro grupo, a grande maioria das contribuições para o FreeBSD vêm de indivíduos desse grupo; A permissão de commit (acesso de escrita) no repositório é concedida a pessoas que contribuem de forma consistente para o projeto. O direito de commit vem acompanhado de responsabilidades adicionais, e para facilitar o aprendizado das mesmas, um mentor é atribuído a todos os novos committers. +
    - Organizao do FreeBSD + Organização do FreeBSD @@ -447,56 +207,32 @@
    - A resoluo de conflitos realizada por um - Core Team de 9 pessoas, o - qual eleito a partir do grupo de - committers. + A resolução de conflitos é realizada por um Core Team de 9 pessoas, o qual é eleito a partir do grupo de committers. - O FreeBSD no tem committers - corporativos. Os committers so obrigados - a assumir de forma individual a responsabilidade pelas - mudanas que introduzem no cdigo. O FreeBSD Committer's - Guide ComGuide documenta as - regras e responsabilidades que se aplicam aos - committers. - - O modelo do projeto FreeBSD examinado em detalhes no - Nik2005. + O FreeBSD não tem committers corporativo. Os committers são obrigados a assumir de forma individual a responsabilidade pelas mudanças que introduzem no código. O FreeBSD Committer's guide ComGuide documenta as regras e responsabilidades que se aplicam aos committers. + + O modelo do projeto FreeBSD é examinado em detalhes no Nik2005.     - Processos de Engenharia para liberao de novas verses - do FreeBSD. + Processos de Engenharia para liberação de novas versões do FreeBSD - O processo de engenharia para a liberao de uma nova - verso do FreeBSD desempenha um papel importante para - assegurar que as suas novas verses sejam de alta qualidade. - Em qualquer ponto do tempo, os voluntrios do FreeBSD suportam - mltiplas verses do cdigo sistema (): - + O processo de engenharia para a liberação de uma nova versão do FreeBSD desempenha um papel importante para assegurar que as suas novas versões sejam de alta qualidade. Em qualquer ponto do tempo, os voluntários do FreeBSD suportam múltiplas versões do código sistema (): + - As novas funcionalidades e os cdigos disruptivos - entram no ramo de desenvolvimento, tambm conhecido como - ramo -CURRENT. + As novas funcionalidades e os códigos disruptivos entram na branch de desenvolvimento, também conhecido como branch -CURRENT. - O ramo -STABLE contm - linhas de cdigo que so ramificadas a partir do HEAD em - intervalos regulares. Apenas cdigo devidamente testado - permitido no ramo -STABLE. Novas funcionalidades so - permitidas aps terem sido testadas e estabilizadas no ramo - -CURRENT. + A branch -STABLE contém linhas de código que são ramificadas a partir do HEAD em intervalos regulares. Apenas código devidamente testado é permitido na branch -STABLE. Novas funcionalidades são permitidas após terem sido testadas e estabilizadas na branch -CURRENT. - O ramo -RELEASE mantido - pela equipe de segurana do FreeBSD. Somente correes de - bugs crticos so permitidos no ramo -RELEASE. + A branch -RELEASE é mantido pela equipe de segurança do FreeBSD. Somente correções de bugs críticos são permitidos na branch -RELEASE.
    - Ramos de verses do FreeBSD + Release Branches do FreeBSD @@ -504,371 +240,190 @@
    - As linhas de cdigo so mantidas vivas enquanto houver - interesse dos usurios e dos desenvolvedores nelas. - - As arquiteturas de mquina esto agrupadas em - tiers; As arquiteturas Tier - 1 so totalmente suportadas pelas equipes de - engenharia de lanamento e de segurana, as arquiteturas - Tier 2 so suportadas em regime de - melhores esforos, e as arquiteturas - experimentais compreendem o Tier 3. A - lista das arquiteturas - suportadas parte da coleo de documentos do - FreeBSD. - - A equipe de engenharia de lanamentos publica um road map - para as verses futuras do FreeBSD no web site do projeto. As - datas indicadas no road map no so prazos; - As novas verses do FreeBSD so liberadas apenas quando o seu - cdigo e documentao esto prontos. - - O processo de engenharia para a liberao de novas verses - do FreeBSD descrito em detalhes no - RelEngDoc. + As linhas de código são mantidas vivas enquanto houver interesse dos usuários e dos desenvolvedores nelas. + As arquiteturas de máquina estão agrupadas em tiers; As arquiteturas Tier 1 são totalmente suportadas pelas equipes de engenharia de lançamento e de segurança, as arquiteturas Tier 2 são suportadas em regime de melhores esforços, e as arquiteturas experimentais compreendem o Tier 3. A lista das arquiteturas suportadas é parte da coleção de documentos do FreeBSD. + + A equipe de engenharia de lançamentos publica um road map para as versões futuras do FreeBSD no web site do projeto. As datas indicadas no road map não são prazos; As novas versões do FreeBSD são liberadas apenas quando o seu código e documentação estão prontos. + + O processo de engenharia para a liberação de novas versões do FreeBSD é descrito em detalhes no RelEngDoc. +     Colaborando com o FreeBSD - Projetos open-source como o FreeBSD - oferecem cdigos finalizados de altssima qualidade - Cov2005. Estudos anteriores examinaram o - efeito da disponibilidade do cdigo fonte no desenvolvimento de - software Com2004. + Projetos open-source como o FreeBSD oferecem códigos finalizados de altíssima qualidade Cov2005. Estudos anteriores examinaram o efeito da disponibilidade do código fonte no desenvolvimento de software Com2004. - Embora o acesso a um cdigo fonte de qualidade possa reduzir - o custo inicial de desenvolvimento, a longo prazo, os custos com - o gerenciamento de mudanas comeam a dominar. A medida que os - ambientes computacionais mudam ao longo dos anos e novas - vulnerabilidades de segurana so descobertas, o seu produto - tambm precisar mudar e se adaptar. O uso de cdigo - open-source no deve ser encarado como uma atividade pontual, - mas sim como um processo contnuo. Os - melhores projetos para se colaborar so os que esto - vivos, ou seja, aqueles com uma - comunidade ativa, que tenha objetivos claros e que possua um - estilo de trabalho transparente. - + Embora o acesso a um código fonte de qualidade possa reduzir o custo inicial de desenvolvimento, a longo prazo, os custos com o gerenciamento de mudanças começam a dominar. A medida que os ambientes computacionais mudam ao longo dos anos e novas vulnerabilidades de segurança são descobertas, o seu produto também precisará mudar e se adaptar. O uso de código open-source não deve ser encarado como uma atividade pontual, mas sim como um processo contínuo. Os melhores projetos para se colaborar são os que estão vivos, ou seja, aqueles com uma comunidade ativa, que tenha objetivos claros e que possua um estilo de trabalho transparente. + - o FreeBSD tem uma comunidade de desenvolvimento ativa - em torno dele. No momento em que este artigo foi escrito, - existiam milhares de colaboradores com representantes de - praticamente todos os continentes povoados do mundo, e mais - de 300 indivduos com acesso de escrita aos repositrios - do projeto. + O FreeBSD tem uma comunidade de desenvolvimento ativa em torno dele. No momento em que este artigo foi escrito, existiam milhares de colaboradores com representantes de praticamente todos os continentes povoados do mundo, e mais de 300 indivíduos com acesso de escrita aos repositórios do projeto. - Os objetivos do projeto FreeBSD so - Hub1994: + Os objetivos do projeto FreeBSD são Hub1994: - Desenvolver um sistema operacional de alta - qualidade para o hardware de computadores populares, - e, + Desenvolver um sistema operacional de alta qualidade para o hardware de computadores populares, e, - Tornar o nosso trabalho disponvel para todos - sob uma licena liberal. + Tornar o nosso trabalho disponível para todos sob uma licença liberal. - O FreeBSD desfruta de uma cultura aberta e - transparente de trabalho. Quase todas as discusses no - projeto ocorrem por e-mail, em listas publicas de - discusso, que tambm so arquivadas para a - posteridade. As polticas do projeto so documentadas - e mantidas sob controle de reviso. A participao no - projeto aberta a todos. + O FreeBSD desfruta de uma cultura aberta e transparente de trabalho. Quase todas as discussões no projeto ocorrem por e-mail, em listas publicas de discussão que também são arquivadas para a posteridade. As políticas do projeto são documentadas e mantidas sob controle de revisão. A participação no projeto é aberta a todos. Compreendendo a cultura do FreeBSD - Para ser capaz de trabalhar de forma eficaz com o projeto - FreeBSD, voc precisa entender a cultura do projeto. + Para ser capaz de trabalhar de forma eficaz com o projeto FreeBSD, você precisa entender a cultura do projeto. - As regras que regem a operao de um projeto voluntrio - so diferentes das que regem a operao de uma empresa com - fins lucrativos. Um erro comum que as empresas cometem ao se - aventurar no mundo open-source o de desvalorizar essas - diferenas. - + As regras que regem a operação de um projeto voluntário são diferentes das que regem a operação de uma empresa com fins lucrativos. Um erro comum que as empresas cometem ao se aventurar no mundo open-source é o de desvalorizar essas diferenças. + + - Motivao + Motivação - A maioria das contribuies feitas para o FreeBSD so - feitas voluntariamente, sem que nenhuma recompensa - financeira esteja envolvida. Os fatores que motivam as - pessoas so complexos, e vo desde o puro altrusmo at o - interesse comum em resolver algum tipo de problema que o - FreeBSD esteja tentando resolver. Neste tipo de ambiente, - a elegncia jamais opcional - Nor1993. + A maioria das contribuições feitas para o FreeBSD são feitas voluntariamente, sem que nenhuma recompensa financeira esteja envolvida. Os fatores que motivam as pessoas são complexos, e vão desde o puro altruísmo até o interesse comum em resolver algum tipo de problema que o FreeBSD esteja tentando resolver. Neste tipo de ambiente, a elegância jamais é opcional Nor1993. - Viso de longo prazo - O FreeBSD tem razes de quase 20 anos para com o - trabalho do Grupo de Pesquisa de Cincias da Computao da - Universidade da Califrnia, Berkeley. - O repositrio - de cdigo fonte do FreeBSD contm a histria do - projeto desde a sua concepo, e existem CDROMs - disponveis que contm o cdigo anterior do - CSRG. - Alguns dos desenvolvedores originais do CSRG - permanecem associados com o projeto. + Visão de Longo Prazo + O FreeBSD tem raízes de quase 20 anos para com o trabalho do Grupo de Pesquisa de Ciências da Computação da Universidade da Califórnia, Berkeley. + O repositório de códigos do FreeBSD contem a história do projeto desde a sua concepção, e existem CDROMs disponíveis que contém código fonte anterior ao CSRG. + Alguns dos desenvolvedores originais do CSRG permanecem associados com o projeto. - O projeto valoriza perspectivas de longo prazo - Nor2001. Uma sigla encontrada com - frequncia no projeto DTRT, a qual - significa Faa a Coisa Certa (Do The - Right Thing). - + O projeto valoriza perspectivas de longo prazo Nor2001. Uma sigla encontrada com frequência no projeto DTRT, a qual significa Faça a Coisa Certa. + Processo de Desenvolvimento - Programas de computador so ferramentas de comunicaco: - em um nvel os programadores comunicam as suas intenes - usando uma notao precisa para uma ferramenta (um compilador) - que traduz as suas instrues para um cdigo executvel. Em - outro nvel, a mesma notao usada para a comunicao das - intenes entre dois programadores. + Programas de computador são ferramentas de comunicacão: em um nível os programadores comunicam as suas intenções usando uma notação precisa para uma ferramenta (um compilador) que traduz as suas instruções para um código executável. Em outro nível, a mesma notação é usada para a comunicação das intenções entre dois programadores. - Especificaes formais e documentos de design raramente - so utilizados no projeto. Cdigo claro e bem escrito, - acompanhado de logs bem escritos para as alteraes das - (), so usados em seu - lugar. O desenvolvimento do FreeBSD acontece por - consenso spero e por cdigo sendo executado - Carp1996. + Especificações formais e documentos de design raramente são utilizados no projeto. Código claro e bem escrito, acompanhado de logs bem escritos para as alterações das () são usados em seu lugar. O desenvolvimento do FreeBSD acontece por consenso áspero e por código sendo executado Carp1996.
    - Um exemplo de entrada no log de alterao + Um exemplo de entrada no log de alteração -bde 2005-10-29 16:34:50 UTC +r151864 | bde | 2005-10-29 09:34:50 -0700 (Sat, 29 Oct 2005) | 13 lines +Changed paths: + M /head/lib/msun/src/e_rem_pio2f.c - FreeBSD src repository +Use double precision to simplify and optimize arg reduction for small +and medium size args too: instead of conditionally subtracting a float +17+24, 17+17+24 or 17+17+17+24 bit approximation to pi/2, always +subtract a double 33+53 bit one. The float version is now closer to +the double version than to old versions of itself -- it uses the same +33+53 bit approximation as the simplest cases in the double version, +and where the float version had to switch to the slow general case at +|x| == 2^7*pi/2, it now switches at |x| == 2^19*pi/2 the same as the +double version. - Modified files: - lib/msun/src e_rem_pio2f.c - Log: - Use double precision to simplify and optimize arg reduction for small - and medium size args too: instead of conditionally subtracting a float - 17+24, 17+17+24 or 17+17+17+24 bit approximation to pi/2, always - subtract a double 33+53 bit one. The float version is now closer to - the double version than to old versions of itself — it uses the same - 33+53 bit approximation as the simplest cases in the double version, - and where the float version had to switch to the slow general case at - |x| == 2^7*pi/2, it now switches at |x| == 2^19*pi/2 the same as the - double version. - - This speeds up arg reduction by a factor of 2 for |x| between 3*pi/4 and - 2^7*pi/4, and by a factor of 7 for |x| between 2^7*pi/4 and 2^19*pi/4. - - Revision Changes Path - 1.14 +22 -97 src/lib/msun/src/e_rem_pio2f.c +This speeds up arg reduction by a factor of 2 for |x| between 3*pi/4 and +2^7*pi/4, and by a factor of 7 for |x| between 2^7*pi/4 and 2^19*pi/4.
    - A comunicao entre os programadores reforada pelo - uso de um &man.style.9; padro de codificao, comum entre - eles. - + A comunicação entre os programadores é reforçada pelo uso de um style9 padrão de codificação, comum entre eles. + - Canais de Comunicao - Os colaboradores do FreeBSD esto espalhados por todo o - mundo. O email (e em menor extenso, o IRC) o meio de - comunicao preferido no projeto. + Canais de Comunicação + Os colaboradores do FreeBSD estão espalhados por todo o mundo. O email (e em menor extensão, o IRC) é o meio de comunicação preferido no projeto.     - Melhores prticas para colaborar com o projeto - FreeBSD. + Melhores práticas para colaborar com o projeto FreeBSD - Agora iremos examinar algumas das melhores prticas para - se fazer um melhor uso do FreeBSD no desenvolvimento de - produtos. - + Agora iremos examinar algumas das melhores práticas para se fazer um melhor uso do FreeBSD no desenvolvimento de produtos. + Se planeje para o longo prazo - Implante processos que o ajudem a monitorar o - desenvolvimento do FreeBSD. Por exemplo: + Implante processos que o ajudem a monitorar o desenvolvimento do FreeBSD. Por exemplo: - Acompanhe o cdigo fonte do FreeBSD - O projeto facilita o espelhamento do seu - repositrio CVS usando o CVSup. - Ter o histrico completo do cdigo fonte til quando - se est debugando problemas complexos e oferece - informaes valiosas sobre as intenes dos - desenvolvedores originais. Utilize um sistema de - controle de cdigo que lhe permita mesclar facilmente - as alteraes entre o cdigo original do FreeBSD e o - seu prprio cdigo. + Acompanhe o código fonte do FreeBSD + O projeto facilita o espelhamento do seu repositório SVN usando svnsync. Ter o histórico completo do código fonte é útil quando se está debugando problemas complexos e oferece informações valiosas sobre as intenções dos desenvolvedores originais. Utilize um sistema de controle de código que lhe permita mesclar facilmente as alterações entre o código original do FreeBSD e o seu próprio código. - A mostra as - anotaes em uma parte do arquivo referenciado pelo log - de alteraes da . A - ascendncia de cada linha de cdigo claramente - visvel. Listagens com as anotaes mostrando a - histria de cada arquivo que faz parte do FreeBSD - esto disponveis na - web. -
    - Cdigo fonte exibindo a listagem de anotaes - gerada utilizando o <command>cvs annotate</command> - + A mostra as anotações em uma parte do arquivo referenciado pelo log de alterações da . A ascendência de cada linha de código é claramente visível. Listagens com as anotações mostrando a história de cada arquivo que faz parte do FreeBSD estão disponíveis na web. +
    + Código fonte exibindo a listagem de anotações gerada utilizando o <command>svn blame</command> -0) { -75 1.15 (bde 06-Nov-05): z = x - pio2; -76 1.15 (bde 06-Nov-05): n = 1; -77 1.15 (bde 06-Nov-05): } else { -78 1.15 (bde 06-Nov-05): z = x + pio2; -79 1.15 (bde 06-Nov-05): n = 3; -80 1.9 (bde 08-Oct-05): } -81 1.15 (bde 06-Nov-05): y[0] = z; -82 1.15 (bde 06-Nov-05): y[1] = z - y[0]; -83 1.15 (bde 06-Nov-05): return n; -84 1.15 (bde 06-Nov-05): } -85 1.15 (bde 06-Nov-05): if(ix<0x407b53d1) { /* |x| < 5*pi/4, special case with n=+-2 */ -]]> +#REV #WHO #DATE #TEXT + +176410 bde 2008-02-19 07:42:46 -0800 (Tue, 19 Feb 2008) #include <sys/cdefs.h> +176410 bde 2008-02-19 07:42:46 -0800 (Tue, 19 Feb 2008) __FBSDID("$FreeBSD$"); + 2116 jkh 1994-08-19 02:40:01 -0700 (Fri, 19 Aug 1994) + 2116 jkh 1994-08-19 02:40:01 -0700 (Fri, 19 Aug 1994) /* __ieee754_rem_pio2f(x,y) + 8870 rgrimes 1995-05-29 22:51:47 -0700 (Mon, 29 May 1995) * +176552 bde 2008-02-25 05:33:20 -0800 (Mon, 25 Feb 2008) * return the remainder of x rem pi/2 in *y +176552 bde 2008-02-25 05:33:20 -0800 (Mon, 25 Feb 2008) * use double precision for everything except passing x +152535 bde 2005-11-16 18:20:04 -0800 (Wed, 16 Nov 2005) * use __kernel_rem_pio2() for large x + 2116 jkh 1994-08-19 02:40:01 -0700 (Fri, 19 Aug 1994) */ + 2116 jkh 1994-08-19 02:40:01 -0700 (Fri, 19 Aug 1994) +176465 bde 2008-02-22 07:55:14 -0800 (Fri, 22 Feb 2008) #include <float.h> +176465 bde 2008-02-22 07:55:14 -0800 (Fri, 22 Feb 2008) + 2116 jkh 1994-08-19 02:40:01 -0700 (Fri, 19 Aug 1994) #include "math.h" +
    - Nomeie um guardio - Nomeie um guardio - (gatekeeper) para monitorar o - desenvolvimento do FreeBSD, para manter-se atento a - mudanas que poderiam potencialmente afetar os seus - produtos. + Nomeie um guardião + Nomeie um guardião para monitorar o desenvolvimento do FreeBSD, para manter-se atento a mudanças que poderiam potencialmente afetar os seus produtos. - Comunique os erros que encontrar de volta para o - projeto - Se voc encontrar um bug no cdigo do FreeBSD que - voc est utilizando, envie um relatrio de - problema. Este procedimento simples ir - ajudar a garantir que voc no precisar corrigir o - erro novamente da prxima vez que precisar importar - novamente do cdigo base do FreeBSD. + Comunique os erros que encontrar de volta para o projeto + Se você encontrar um bug no código do FreeBSD que você está utilizando, envie um bug report. Este procedimento simples irá ajudar a garantir que você não precisará corrigir o erro novamente da próxima vez que precisar importar novamente do código base do FreeBSD. - Se alavanque nos esforos de engenharia do FreeBSD - para lanamento de novas verses. + Se alavanque nos esforços de engenharia do FreeBSD para lançamento de novas versões - Utilize cdigo do ramo de desenvolvimento -STABLE - do FreeBSD. Este ramo de desenvolvimento formalmente - suportado pelas equipes de engenharia de lanamento e de - segurana, e formada apenas por cdigo - testado. + Utilize código da branch de desenvolvimento -STABLE do FreeBSD. Este branch de desenvolvimento é formalmente suportado pelas equipes de engenharia de lançamento e de segurança, e é formada apenas por código testado. - Doe cdigo para reduzir seus custos + Doe código para reduzir seus custos - Uma parte significativa dos custos relacionados - ao desenvolvimento de um produto o de realizar a sua - manuteno. Ao doar partes no criticas do seu cdigo - para o projeto, voc se beneficia por ter o seu cdigo - exposto de uma forma ampla, exposio que ele no teria - de outra forma. Esta exposio por sua vez leva - eliminao de um maior numero de bugs e de - vulnerabilidades de segurana, e permite que anomalias - de desempenho sejam identificadas e - corrigidas. + Uma parte significativa dos custos relacionados ao desenvolvimento de um produto é o de realizar a sua manutenção. Ao doar partes não criticas do seu código para o projeto, você se beneficia por ter o seu código exposto de uma forma ampla, exposição que ele não teria de outra forma. Esta exposição por sua vez leva eliminação de um maior numero de bugs e de vulnerabilidades de segurança, e permite que anomalias de desempenho sejam identificadas e corrigidas. Obtenha suporte efetivo *** DIFF OUTPUT TRUNCATED AT 1000 LINES *** From owner-svn-doc-head@freebsd.org Tue Aug 28 10:11:40 2018 Return-Path: Delivered-To: svn-doc-head@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 452D810870FB; Tue, 28 Aug 2018 10:11:40 +0000 (UTC) (envelope-from ygy@FreeBSD.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mxrelay.nyi.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E4DBC7CBF1; Tue, 28 Aug 2018 10:11:39 +0000 (UTC) (envelope-from ygy@FreeBSD.org) Received: from repo.freebsd.org (repo.freebsd.org [IPv6:2610:1c1:1:6068::e6a:0]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id C5EE23236; Tue, 28 Aug 2018 10:11:39 +0000 (UTC) (envelope-from ygy@FreeBSD.org) Received: from repo.freebsd.org ([127.0.1.37]) by repo.freebsd.org (8.15.2/8.15.2) with ESMTP id w7SABdHo041674; Tue, 28 Aug 2018 10:11:39 GMT (envelope-from ygy@FreeBSD.org) Received: (from ygy@localhost) by repo.freebsd.org (8.15.2/8.15.2/Submit) id w7SABdAZ041673; Tue, 28 Aug 2018 10:11:39 GMT (envelope-from ygy@FreeBSD.org) Message-Id: <201808281011.w7SABdAZ041673@repo.freebsd.org> X-Authentication-Warning: repo.freebsd.org: ygy set sender to ygy@FreeBSD.org using -f From: Guangyuan Yang Date: Tue, 28 Aug 2018 10:11:39 +0000 (UTC) To: doc-committers@freebsd.org, svn-doc-all@freebsd.org, svn-doc-head@freebsd.org Subject: svn commit: r52186 - head/en_US.ISO8859-1/articles/contributors X-SVN-Group: doc-head X-SVN-Commit-Author: ygy X-SVN-Commit-Paths: head/en_US.ISO8859-1/articles/contributors X-SVN-Commit-Revision: 52186 X-SVN-Commit-Repository: doc MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-BeenThere: svn-doc-head@freebsd.org X-Mailman-Version: 2.1.27 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, 28 Aug 2018 10:11:40 -0000 Author: ygy Date: Tue Aug 28 10:11:39 2018 New Revision: 52186 URL: https://svnweb.freebsd.org/changeset/doc/52186 Log: Add Qiang Guo to contributors. Maintainer of: sysutils/bvm PR: 230320 Modified: head/en_US.ISO8859-1/articles/contributors/contrib.additional.xml Modified: head/en_US.ISO8859-1/articles/contributors/contrib.additional.xml ============================================================================== --- head/en_US.ISO8859-1/articles/contributors/contrib.additional.xml Tue Aug 28 03:24:45 2018 (r52185) +++ head/en_US.ISO8859-1/articles/contributors/contrib.additional.xml Tue Aug 28 10:11:39 2018 (r52186) @@ -8836,6 +8836,11 @@ + Qiang Guo + guoqiang_cn@126.com + + + Qing Feng qingfeng@me.com From owner-svn-doc-head@freebsd.org Tue Aug 28 15:32:16 2018 Return-Path: Delivered-To: svn-doc-head@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 1191A108F8CC; Tue, 28 Aug 2018 15:32:16 +0000 (UTC) (envelope-from ryusuke@FreeBSD.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mxrelay.nyi.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id BB02189FA0; Tue, 28 Aug 2018 15:32:15 +0000 (UTC) (envelope-from ryusuke@FreeBSD.org) Received: from repo.freebsd.org (repo.freebsd.org [IPv6:2610:1c1:1:6068::e6a:0]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 82FBD6BD1; Tue, 28 Aug 2018 15:32:15 +0000 (UTC) (envelope-from ryusuke@FreeBSD.org) Received: from repo.freebsd.org ([127.0.1.37]) by repo.freebsd.org (8.15.2/8.15.2) with ESMTP id w7SFWFt0012801; Tue, 28 Aug 2018 15:32:15 GMT (envelope-from ryusuke@FreeBSD.org) Received: (from ryusuke@localhost) by repo.freebsd.org (8.15.2/8.15.2/Submit) id w7SFWFNM012799; Tue, 28 Aug 2018 15:32:15 GMT (envelope-from ryusuke@FreeBSD.org) Message-Id: <201808281532.w7SFWFNM012799@repo.freebsd.org> X-Authentication-Warning: repo.freebsd.org: ryusuke set sender to ryusuke@FreeBSD.org using -f From: Ryusuke SUZUKI Date: Tue, 28 Aug 2018 15:32:15 +0000 (UTC) To: doc-committers@freebsd.org, svn-doc-all@freebsd.org, svn-doc-head@freebsd.org Subject: svn commit: r52187 - in head/ja_JP.eucJP/books/handbook: kernelconfig multimedia X-SVN-Group: doc-head X-SVN-Commit-Author: ryusuke X-SVN-Commit-Paths: in head/ja_JP.eucJP/books/handbook: kernelconfig multimedia X-SVN-Commit-Revision: 52187 X-SVN-Commit-Repository: doc MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-BeenThere: svn-doc-head@freebsd.org X-Mailman-Version: 2.1.27 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, 28 Aug 2018 15:32:16 -0000 Author: ryusuke Date: Tue Aug 28 15:32:14 2018 New Revision: 52187 URL: https://svnweb.freebsd.org/changeset/doc/52187 Log: - Merge the following from the English version: r50592 -> r52157 head/ja_JP.eucJP/books/handbook/kernelconfig/chapter.xml r51486 -> r52152 head/ja_JP.eucJP/books/handbook/multimedia/chapter.xml Modified: head/ja_JP.eucJP/books/handbook/kernelconfig/chapter.xml head/ja_JP.eucJP/books/handbook/multimedia/chapter.xml Modified: head/ja_JP.eucJP/books/handbook/kernelconfig/chapter.xml ============================================================================== --- head/ja_JP.eucJP/books/handbook/kernelconfig/chapter.xml Tue Aug 28 10:11:39 2018 (r52186) +++ head/ja_JP.eucJP/books/handbook/kernelconfig/chapter.xml Tue Aug 28 15:32:14 2018 (r52187) @@ -3,7 +3,7 @@ The FreeBSD Documentation Project The FreeBSD Japanese Documentation Project - Original revision: r50592 + Original revision: r52157 $FreeBSD$ --> amd64, i386, ia64, - pc98, powerpc + powerpc sparc64 Υ֥ǥ쥯ȥ꤬ޤ ƥƥΥǥ쥯ȥˤեϤ٤ƤΥƥǤΤ߻Ѥޤ ĤΥɤϡƥ˰¸ʤ Modified: head/ja_JP.eucJP/books/handbook/multimedia/chapter.xml ============================================================================== --- head/ja_JP.eucJP/books/handbook/multimedia/chapter.xml Tue Aug 28 10:11:39 2018 (r52186) +++ head/ja_JP.eucJP/books/handbook/multimedia/chapter.xml Tue Aug 28 15:32:14 2018 (r52187) @@ -3,7 +3,7 @@ The FreeBSD Documentation Project The FreeBSD Japanese Documentation Project - Original revision: r51486 + Original revision: r52152 $FreeBSD$ --> Ǹ˥ХåɤưƤ - &prompt.root; echo 'mythbackend_enable="YES"' >> /etc/rc.conf + &prompt.root; sysrc mythbackend_enable=yes &prompt.root; service mythbackend start From owner-svn-doc-head@freebsd.org Tue Aug 28 22:21:06 2018 Return-Path: Delivered-To: svn-doc-head@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 88E7A109967D; Tue, 28 Aug 2018 22:21:06 +0000 (UTC) (envelope-from ebrandi@FreeBSD.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mxrelay.nyi.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 3F5ED70C69; Tue, 28 Aug 2018 22:21:06 +0000 (UTC) (envelope-from ebrandi@FreeBSD.org) Received: from repo.freebsd.org (repo.freebsd.org [IPv6:2610:1c1:1:6068::e6a:0]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 20985146A8; Tue, 28 Aug 2018 22:21:06 +0000 (UTC) (envelope-from ebrandi@FreeBSD.org) Received: from repo.freebsd.org ([127.0.1.37]) by repo.freebsd.org (8.15.2/8.15.2) with ESMTP id w7SML6U2025272; Tue, 28 Aug 2018 22:21:06 GMT (envelope-from ebrandi@FreeBSD.org) Received: (from ebrandi@localhost) by repo.freebsd.org (8.15.2/8.15.2/Submit) id w7SML6MN025271; Tue, 28 Aug 2018 22:21:06 GMT (envelope-from ebrandi@FreeBSD.org) Message-Id: <201808282221.w7SML6MN025271@repo.freebsd.org> X-Authentication-Warning: repo.freebsd.org: ebrandi set sender to ebrandi@FreeBSD.org using -f From: Edson Brandi Date: Tue, 28 Aug 2018 22:21:06 +0000 (UTC) To: doc-committers@freebsd.org, svn-doc-all@freebsd.org, svn-doc-head@freebsd.org Subject: svn commit: r52188 - head/en_US.ISO8859-1/books/faq X-SVN-Group: doc-head X-SVN-Commit-Author: ebrandi X-SVN-Commit-Paths: head/en_US.ISO8859-1/books/faq X-SVN-Commit-Revision: 52188 X-SVN-Commit-Repository: doc MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-BeenThere: svn-doc-head@freebsd.org X-Mailman-Version: 2.1.27 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, 28 Aug 2018 22:21:06 -0000 Author: ebrandi Date: Tue Aug 28 22:21:05 2018 New Revision: 52188 URL: https://svnweb.freebsd.org/changeset/doc/52188 Log: Correction of a small typo error in the FAQ, during the translation of the FAQ from en_US to pt_BR I found a small typo in which the word "accept" was replaced with the word "except", and this error changes the context of the answer. Submitted by: ebrandi Reviewed by: sevan, eadler Approved by: gabor Differential Revision: https://reviews.freebsd.org/D16927 Modified: head/en_US.ISO8859-1/books/faq/book.xml Modified: head/en_US.ISO8859-1/books/faq/book.xml ============================================================================== --- head/en_US.ISO8859-1/books/faq/book.xml Tue Aug 28 15:32:14 2018 (r52187) +++ head/en_US.ISO8859-1/books/faq/book.xml Tue Aug 28 22:21:05 2018 (r52188) @@ -7150,7 +7150,7 @@ hint.sio.7.irq="12" - We except all types of contributions: documentation, + We accept all types of contributions: documentation, code, and even art. See the article on Contributing to &os; for specific advice on how to do From owner-svn-doc-head@freebsd.org Tue Aug 28 22:39:14 2018 Return-Path: Delivered-To: svn-doc-head@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8D0C81099C2C; Tue, 28 Aug 2018 22:39:14 +0000 (UTC) (envelope-from rpokala@FreeBSD.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mxrelay.nyi.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 3F5AA71486; Tue, 28 Aug 2018 22:39:14 +0000 (UTC) (envelope-from rpokala@FreeBSD.org) Received: from repo.freebsd.org (repo.freebsd.org [IPv6:2610:1c1:1:6068::e6a:0]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 203B6149CA; Tue, 28 Aug 2018 22:39:14 +0000 (UTC) (envelope-from rpokala@FreeBSD.org) Received: from repo.freebsd.org ([127.0.1.37]) by repo.freebsd.org (8.15.2/8.15.2) with ESMTP id w7SMdD8d032237; Tue, 28 Aug 2018 22:39:13 GMT (envelope-from rpokala@FreeBSD.org) Received: (from rpokala@localhost) by repo.freebsd.org (8.15.2/8.15.2/Submit) id w7SMdCYh032232; Tue, 28 Aug 2018 22:39:12 GMT (envelope-from rpokala@FreeBSD.org) Message-Id: <201808282239.w7SMdCYh032232@repo.freebsd.org> X-Authentication-Warning: repo.freebsd.org: rpokala set sender to rpokala@FreeBSD.org using -f From: Ravi Pokala Date: Tue, 28 Aug 2018 22:39:12 +0000 (UTC) To: doc-committers@freebsd.org, svn-doc-all@freebsd.org, svn-doc-head@freebsd.org Subject: svn commit: r52189 - in head: en_US.ISO8859-1/articles/contributors share/pgpkeys share/xml X-SVN-Group: doc-head X-SVN-Commit-Author: rpokala X-SVN-Commit-Paths: in head: en_US.ISO8859-1/articles/contributors share/pgpkeys share/xml X-SVN-Commit-Revision: 52189 X-SVN-Commit-Repository: doc MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-BeenThere: svn-doc-head@freebsd.org X-Mailman-Version: 2.1.27 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, 28 Aug 2018 22:39:14 -0000 Author: rpokala (src committer) Date: Tue Aug 28 22:39:12 2018 New Revision: 52189 URL: https://svnweb.freebsd.org/changeset/doc/52189 Log: I forgot to update the docs with my keys when I first got my commit bit. Bad rpokala! Pointy-hat to: rpokala Reviewed by: zeising Differential Revision: https://reviews.freebsd.org/D16915 Added: head/share/pgpkeys/rpokala.key (contents, props changed) Modified: head/en_US.ISO8859-1/articles/contributors/contrib.committers.xml head/share/pgpkeys/pgpkeys-developers.xml head/share/pgpkeys/pgpkeys.ent head/share/xml/authors.ent head/share/xml/news.xml Modified: head/en_US.ISO8859-1/articles/contributors/contrib.committers.xml ============================================================================== --- head/en_US.ISO8859-1/articles/contributors/contrib.committers.xml Tue Aug 28 22:21:05 2018 (r52188) +++ head/en_US.ISO8859-1/articles/contributors/contrib.committers.xml Tue Aug 28 22:39:12 2018 (r52189) @@ -1070,6 +1070,10 @@ xmlns:xlink="http://www.w3.org/1999/xlink" version="5. + &a.rpokala.email; + + + &a.arrowd.email; Modified: head/share/pgpkeys/pgpkeys-developers.xml ============================================================================== --- head/share/pgpkeys/pgpkeys-developers.xml Tue Aug 28 22:21:05 2018 (r52188) +++ head/share/pgpkeys/pgpkeys-developers.xml Tue Aug 28 22:39:12 2018 (r52189) @@ -1866,6 +1866,11 @@ &pgpkey.pizzamig; + + &a.rpokala.email; + &pgpkey.rpokala; + + &a.jdp.email; &pgpkey.jdp; Modified: head/share/pgpkeys/pgpkeys.ent ============================================================================== --- head/share/pgpkeys/pgpkeys.ent Tue Aug 28 22:21:05 2018 (r52188) +++ head/share/pgpkeys/pgpkeys.ent Tue Aug 28 22:39:12 2018 (r52189) @@ -450,6 +450,7 @@ + Added: head/share/pgpkeys/rpokala.key ============================================================================== --- /dev/null 00:00:00 1970 (empty, because file is newly added) +++ head/share/pgpkeys/rpokala.key Tue Aug 28 22:39:12 2018 (r52189) @@ -0,0 +1,43 @@ + + + +sub rsa2048/02821157C36360C6 2018-08-27 [E] [expires: 2021-08-26] + +]]> + Modified: head/share/xml/authors.ent ============================================================================== --- head/share/xml/authors.ent Tue Aug 28 22:21:05 2018 (r52188) +++ head/share/xml/authors.ent Tue Aug 28 22:39:12 2018 (r52189) @@ -1965,6 +1965,9 @@ rlibby@FreeBSD.org"> + +rpokala@FreeBSD.org"> + rm@FreeBSD.org"> Modified: head/share/xml/news.xml ============================================================================== --- head/share/xml/news.xml Tue Aug 28 22:21:05 2018 (r52188) +++ head/share/xml/news.xml Tue Aug 28 22:39:12 2018 (r52189) @@ -1828,6 +1828,15 @@ 11 + 13 + + +

    New committer: + Ravi Pokala (src)

    +     +     + + 1 From owner-svn-doc-head@freebsd.org Tue Aug 28 23:52:44 2018 Return-Path: Delivered-To: svn-doc-head@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 31663109AF2B; Tue, 28 Aug 2018 23:52:44 +0000 (UTC) (envelope-from dbaio@FreeBSD.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mxrelay.nyi.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D75C973441; Tue, 28 Aug 2018 23:52:43 +0000 (UTC) (envelope-from dbaio@FreeBSD.org) Received: from repo.freebsd.org (repo.freebsd.org [IPv6:2610:1c1:1:6068::e6a:0]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id B8888156FD; Tue, 28 Aug 2018 23:52:43 +0000 (UTC) (envelope-from dbaio@FreeBSD.org) Received: from repo.freebsd.org ([127.0.1.37]) by repo.freebsd.org (8.15.2/8.15.2) with ESMTP id w7SNqhgr073013; Tue, 28 Aug 2018 23:52:43 GMT (envelope-from dbaio@FreeBSD.org) Received: (from dbaio@localhost) by repo.freebsd.org (8.15.2/8.15.2/Submit) id w7SNqhjJ073012; Tue, 28 Aug 2018 23:52:43 GMT (envelope-from dbaio@FreeBSD.org) Message-Id: <201808282352.w7SNqhjJ073012@repo.freebsd.org> X-Authentication-Warning: repo.freebsd.org: dbaio set sender to dbaio@FreeBSD.org using -f From: "Danilo G. Baio" Date: Tue, 28 Aug 2018 23:52:43 +0000 (UTC) To: doc-committers@freebsd.org, svn-doc-all@freebsd.org, svn-doc-head@freebsd.org Subject: svn commit: r52190 - head/share/mk X-SVN-Group: doc-head X-SVN-Commit-Author: dbaio X-SVN-Commit-Paths: head/share/mk X-SVN-Commit-Revision: 52190 X-SVN-Commit-Repository: doc MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-BeenThere: svn-doc-head@freebsd.org X-Mailman-Version: 2.1.27 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, 28 Aug 2018 23:52:44 -0000 Author: dbaio (ports committer) Date: Tue Aug 28 23:52:43 2018 New Revision: 52190 URL: https://svnweb.freebsd.org/changeset/doc/52190 Log: share/mk/doc.translate.mk: Improve `make po` - Create .pot (Portable Object Template) files for the en_US documents Do not ignore en_US language and generate a `.pot` file instead of a `.po`. These are used as template for tools like Zanata. - Execute `msgattrib` even on a new `[.po|.pot]` file This will be useful to wrap long message lines and avoid bigger diffs in the future. Approved by: wosch Differential Revision: https://reviews.freebsd.org/D16726 Modified: head/share/mk/doc.translate.mk Modified: head/share/mk/doc.translate.mk ============================================================================== --- head/share/mk/doc.translate.mk Tue Aug 28 22:39:12 2018 (r52189) +++ head/share/mk/doc.translate.mk Tue Aug 28 23:52:43 2018 (r52190) @@ -42,9 +42,6 @@ POSET_CMD= ${SED} -i '' -e '1s,^,\#${IDSTR1}${IDSTR2}\ MASTER_SRCS!= ${MAKE} -C ${EN_DIR} -V SRCS ${DOC}.translate.xml: -.if ${TRAN_DIR} == ${EN_DIR} - @${ECHO} "Please build PO file only in a non-English directory, ignored" -.else # some SRCS files might need to be generated, make sure they exist @${MAKE} -C ${EN_DIR} ${MASTER_SRCS} > /dev/null # normalize the English original into a single file @@ -52,32 +49,34 @@ ${DOC}.translate.xml: # remove redundant namespace attributes @${PO_XMLLINT} --nsclean ${.TARGET}.tmp > ${.TARGET} @${RM} ${.TARGET}.tmp - @${MAKE} -C ${EN_DIR} clean > /dev/null -.endif .if ${TRAN_DIR} == ${EN_DIR} -po: +PO_FILE=${PO_LANG}.pot .else -po: ${PO_LANG}.po +PO_FILE=${PO_LANG}.po .endif +po: ${PO_FILE} .PHONY: po -${PO_LANG}.po: ${DOC}.translate.xml - @${ITSTOOL} -o ${PO_LANG}.po.tmp ${DOC}.translate.xml -.if exists(${PO_LANG}.po) - @${ECHO} "${PO_LANG}.po exists, merging" - @${MSGMERGE} -o ${PO_LANG}.po.new ${PO_LANG}.po ${PO_LANG}.po.tmp - @${MSGATTRIB} --no-obsolete -o ${PO_LANG}.po.tmp ${PO_LANG}.po.new - @${RM} ${PO_LANG}.po.new - @${MV} ${PO_LANG}.po.tmp ${PO_LANG}.po +${PO_FILE}: ${DOC}.translate.xml + @${ITSTOOL} -o ${PO_FILE}.tmp ${DOC}.translate.xml +.if exists(${PO_FILE}) + @${ECHO} "${PO_FILE} exists, merging" + @${MSGMERGE} -o ${PO_FILE}.new ${PO_FILE} ${PO_FILE}.tmp + @${MSGATTRIB} --no-obsolete -o ${PO_FILE}.tmp ${PO_FILE}.new + @${RM} ${PO_FILE}.new + @${MV} ${PO_FILE}.tmp ${PO_FILE} .else - @${ECHO} "${PO_LANG}.po created, please check and correct the settings in the header" - @${MV} ${PO_LANG}.po.tmp ${PO_LANG}.po + @${ECHO} "${PO_FILE} created, please check and correct the settings in the header" + # Just to wrap long message lines + @${MSGATTRIB} -o ${PO_FILE} ${PO_FILE}.tmp + @${RM} ${PO_FILE}.tmp @${POSET_CMD} ${.TARGET} .endif + @${MAKE} -C ${EN_DIR} clean > /dev/null -${PO_LANG}.mo: ${PO_LANG}.po +${PO_LANG}.mo: ${PO_FILE} @${MSGFMT} -o ${.TARGET} ${.ALLSRC} tran ${DOC}.xml: ${DOC}.translate.xml ${PO_LANG}.mo From owner-svn-doc-head@freebsd.org Wed Aug 29 13:31:31 2018 Return-Path: Delivered-To: svn-doc-head@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D65A5108A7A1; Wed, 29 Aug 2018 13:31:31 +0000 (UTC) (envelope-from ryusuke@FreeBSD.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mxrelay.nyi.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 8C4C18D194; Wed, 29 Aug 2018 13:31:31 +0000 (UTC) (envelope-from ryusuke@FreeBSD.org) Received: from repo.freebsd.org (repo.freebsd.org [IPv6:2610:1c1:1:6068::e6a:0]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 6DA161DCF4; Wed, 29 Aug 2018 13:31:31 +0000 (UTC) (envelope-from ryusuke@FreeBSD.org) Received: from repo.freebsd.org ([127.0.1.37]) by repo.freebsd.org (8.15.2/8.15.2) with ESMTP id w7TDVVE1090433; Wed, 29 Aug 2018 13:31:31 GMT (envelope-from ryusuke@FreeBSD.org) Received: (from ryusuke@localhost) by repo.freebsd.org (8.15.2/8.15.2/Submit) id w7TDVV4W090432; Wed, 29 Aug 2018 13:31:31 GMT (envelope-from ryusuke@FreeBSD.org) Message-Id: <201808291331.w7TDVV4W090432@repo.freebsd.org> X-Authentication-Warning: repo.freebsd.org: ryusuke set sender to ryusuke@FreeBSD.org using -f From: Ryusuke SUZUKI Date: Wed, 29 Aug 2018 13:31:31 +0000 (UTC) To: doc-committers@freebsd.org, svn-doc-all@freebsd.org, svn-doc-head@freebsd.org Subject: svn commit: r52191 - head/ja_JP.eucJP/share/xml X-SVN-Group: doc-head X-SVN-Commit-Author: ryusuke X-SVN-Commit-Paths: head/ja_JP.eucJP/share/xml X-SVN-Commit-Revision: 52191 X-SVN-Commit-Repository: doc MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-BeenThere: svn-doc-head@freebsd.org X-Mailman-Version: 2.1.27 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, 29 Aug 2018 13:31:32 -0000 Author: ryusuke Date: Wed Aug 29 13:31:31 2018 New Revision: 52191 URL: https://svnweb.freebsd.org/changeset/doc/52191 Log: - Merge the following from the English version: r52120 -> r52189 head/ja_JP.eucJP/share/xml/news.xml Modified: head/ja_JP.eucJP/share/xml/news.xml Modified: head/ja_JP.eucJP/share/xml/news.xml ============================================================================== --- head/ja_JP.eucJP/share/xml/news.xml Tue Aug 28 23:52:43 2018 (r52190) +++ head/ja_JP.eucJP/share/xml/news.xml Wed Aug 29 13:31:31 2018 (r52191) @@ -23,7 +23,7 @@ would like to work on. *** $FreeBSD$ - Original revision: r52120 + Original revision: r52189 --> @@ -1851,6 +1851,15 @@ 11 + + + 13 + + +

    ߥåǤ: + Ravi Pokala (src)

    +     +     1 From owner-svn-doc-head@freebsd.org Thu Aug 30 10:31:44 2018 Return-Path: Delivered-To: svn-doc-head@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3F9AF109B1A0; Thu, 30 Aug 2018 10:31:44 +0000 (UTC) (envelope-from ebrandi@FreeBSD.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mxrelay.nyi.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id EB3087AEB6; Thu, 30 Aug 2018 10:31:43 +0000 (UTC) (envelope-from ebrandi@FreeBSD.org) Received: from repo.freebsd.org (repo.freebsd.org [IPv6:2610:1c1:1:6068::e6a:0]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id CBD1C3038; Thu, 30 Aug 2018 10:31:43 +0000 (UTC) (envelope-from ebrandi@FreeBSD.org) Received: from repo.freebsd.org ([127.0.1.37]) by repo.freebsd.org (8.15.2/8.15.2) with ESMTP id w7UAVhU3046358; Thu, 30 Aug 2018 10:31:43 GMT (envelope-from ebrandi@FreeBSD.org) Received: (from ebrandi@localhost) by repo.freebsd.org (8.15.2/8.15.2/Submit) id w7UAVht0046357; Thu, 30 Aug 2018 10:31:43 GMT (envelope-from ebrandi@FreeBSD.org) Message-Id: <201808301031.w7UAVht0046357@repo.freebsd.org> X-Authentication-Warning: repo.freebsd.org: ebrandi set sender to ebrandi@FreeBSD.org using -f From: Edson Brandi Date: Thu, 30 Aug 2018 10:31:43 +0000 (UTC) To: doc-committers@freebsd.org, svn-doc-all@freebsd.org, svn-doc-head@freebsd.org Subject: svn commit: r52192 - head/en_US.ISO8859-1/articles/freebsd-questions X-SVN-Group: doc-head X-SVN-Commit-Author: ebrandi X-SVN-Commit-Paths: head/en_US.ISO8859-1/articles/freebsd-questions X-SVN-Commit-Revision: 52192 X-SVN-Commit-Repository: doc MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-BeenThere: svn-doc-head@freebsd.org X-Mailman-Version: 2.1.27 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: Thu, 30 Aug 2018 10:31:44 -0000 Author: ebrandi Date: Thu Aug 30 10:31:43 2018 New Revision: 52192 URL: https://svnweb.freebsd.org/changeset/doc/52192 Log: Removing reference to disabled search service While reviewing the translated version of this article (pt_BR) I saw that the Google service for specific BSD searches referenced in this article was disabled in 2011. There is more details about this service being discontinued at: https://www.freebsdnews.com/2011/06/08/google-discontinues-bsd-search-google-combsd/ Submitted by: ebrandi Reviewed by: allanjude, eadler Approved by: gabor Differential Revision: https://reviews.freebsd.org/D16949 Modified: head/en_US.ISO8859-1/articles/freebsd-questions/article.xml Modified: head/en_US.ISO8859-1/articles/freebsd-questions/article.xml ============================================================================== --- head/en_US.ISO8859-1/articles/freebsd-questions/article.xml Wed Aug 29 13:31:31 2018 (r52191) +++ head/en_US.ISO8859-1/articles/freebsd-questions/article.xml Thu Aug 30 10:31:43 2018 (r52192) @@ -242,7 +242,6 @@ your options page that will email your current passwor Use a search engine such as Google or Yahoo to find answers to your question. - Google even has a BSD-specific search interface. From owner-svn-doc-head@freebsd.org Thu Aug 30 11:06:49 2018 Return-Path: Delivered-To: svn-doc-head@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 83FD2109BA13; Thu, 30 Aug 2018 11:06:49 +0000 (UTC) (envelope-from ebrandi@FreeBSD.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mxrelay.nyi.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 2F86F7BCCE; Thu, 30 Aug 2018 11:06:49 +0000 (UTC) (envelope-from ebrandi@FreeBSD.org) Received: from repo.freebsd.org (repo.freebsd.org [IPv6:2610:1c1:1:6068::e6a:0]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 0B65838D4; Thu, 30 Aug 2018 11:06:49 +0000 (UTC) (envelope-from ebrandi@FreeBSD.org) Received: from repo.freebsd.org ([127.0.1.37]) by repo.freebsd.org (8.15.2/8.15.2) with ESMTP id w7UB6ncI067805; Thu, 30 Aug 2018 11:06:49 GMT (envelope-from ebrandi@FreeBSD.org) Received: (from ebrandi@localhost) by repo.freebsd.org (8.15.2/8.15.2/Submit) id w7UB6m8d067803; Thu, 30 Aug 2018 11:06:48 GMT (envelope-from ebrandi@FreeBSD.org) Message-Id: <201808301106.w7UB6m8d067803@repo.freebsd.org> X-Authentication-Warning: repo.freebsd.org: ebrandi set sender to ebrandi@FreeBSD.org using -f From: Edson Brandi Date: Thu, 30 Aug 2018 11:06:48 +0000 (UTC) To: doc-committers@freebsd.org, svn-doc-all@freebsd.org, svn-doc-head@freebsd.org Subject: svn commit: r52193 - head/pt_BR.ISO8859-1/articles/explaining-bsd X-SVN-Group: doc-head X-SVN-Commit-Author: ebrandi X-SVN-Commit-Paths: head/pt_BR.ISO8859-1/articles/explaining-bsd X-SVN-Commit-Revision: 52193 X-SVN-Commit-Repository: doc MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-BeenThere: svn-doc-head@freebsd.org X-Mailman-Version: 2.1.27 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: Thu, 30 Aug 2018 11:06:49 -0000 Author: ebrandi Date: Thu Aug 30 11:06:48 2018 New Revision: 52193 URL: https://svnweb.freebsd.org/changeset/doc/52193 Log: pt_BR.ISO8859-1/articles/explaining-bsd: converted to .po * content synchronized with en_US document (rev 51926) * article.xml converted to .po * .po file was translated to pt_BR * .po and .xml file has been set to UTF-8 encoding * information about volunteers who translated and/or revised the document was added to the header of the .po file Submitted by: ebrandi Reviewed by: gabor, dbaio Approved by: gabor (mentor) Obtained from: The FreeBSD Brazilian Portuguese Documentation Project Differential Revision: https://reviews.freebsd.org/D16932 Added: head/pt_BR.ISO8859-1/articles/explaining-bsd/pt_BR.po (contents, props changed) Modified: head/pt_BR.ISO8859-1/articles/explaining-bsd/article.xml (contents, props changed) Modified: head/pt_BR.ISO8859-1/articles/explaining-bsd/article.xml ============================================================================== --- head/pt_BR.ISO8859-1/articles/explaining-bsd/article.xml Thu Aug 30 10:31:43 2018 (r52192) +++ head/pt_BR.ISO8859-1/articles/explaining-bsd/article.xml Thu Aug 30 11:06:48 2018 (r52193) @@ -1,737 +1,279 @@ - - - + +
    + + Explicando o BSD - Original revision: r39544 + GregLehey
    grog@FreeBSD.org
     - $FreeBSD$ - ---> -
    - Explicando o BSD - - - GregLehey -
    grog@FreeBSD.org
    -     - - &tm-attrib.freebsd; - &tm-attrib.amd; - &tm-attrib.apple; - &tm-attrib.intel; - &tm-attrib.linux; - &tm-attrib.opengroup; - &tm-attrib.sparc; - &tm-attrib.sun; - &tm-attrib.unix; - &tm-attrib.general; + FreeBSD is a registered trademark of the FreeBSD Foundation. + AMD, AMD Athlon, AMD Opteron, AMD Phenom, AMD Sempron, AMD Turion, Athlon, Élan, Opteron, and PCnet are trademarks of Advanced Micro Devices, Inc. + Apple, AirPort, FireWire, iMac, iPhone, iPad, Mac, Macintosh, Mac OS, Quicktime, and TrueType are trademarks of Apple Inc., registered in the U.S. and other countries. + Intel, Celeron, Centrino, Core, EtherExpress, i386, i486, Itanium, Pentium, and Xeon are trademarks or registered trademarks of Intel Corporation or its subsidiaries in the United States and other countries. + Linux is a registered trademark of Linus Torvalds. + Motif, OSF/1, and UNIX are registered trademarks and IT DialTone and The Open Group are trademarks of The Open Group in the United States and other countries. + SPARC, SPARC64, and UltraSPARC are trademarks of SPARC International, Inc in the United States and other countries. SPARC International, Inc owns all of the SPARC trademarks and under licensing agreements allows the proper use of these trademarks by its members. + Sun, Sun Microsystems, Java, Java Virtual Machine, JDK, JRE, JSP, JVM, Netra, OpenJDK, Solaris, StarOffice, SunOS and VirtualBox are trademarks or registered trademarks of Sun Microsystems, Inc. in the United States and other countries. + UNIX is a registered trademark of The Open Group in the United States and other countries. + Many of the designations used by manufacturers and sellers to distinguish their products are claimed as trademarks. Where those designations appear in this document, and the FreeBSD Project was aware of the trademark claim, the designations have been followed by the ™ or the ® symbol. - + $FreeBSD$ - + $FreeBSD$ - No mundo do open source, a palavra Linux - quase um sinnimo de Sistema Operacional, - mas esse no o nico sistema operacional &unix; - de cdigo aberto. De acordo com o - Contador de Sistemas Operacionais da Internet, em - Abril de 1999 31.3% das mquinas conectadas na rede - rodam Linux. 14.6% rodam BSD &unix;. Alguns dos - responsveis pelas maiores operaes 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 - no se trata de um nicho de mercado: O BSD um - segredo muito bem guardado. + No mundo do código aberto, a palavra Linux é praticamente sinônimo de Sistema Operacional, mas ele não é o único sistema operacional UNIX de código aberto. - Ento, qual o segredo? Por que o BSD - no melhor difundido, mais conhecido? Esse - documento abordar essas e outras - questes. + Então, qual é o segredo? Por que o BSD não é mais conhecido? Este artigo aborda esta e outras questões. - Ao longo desse documento, as diferenas entre o BSD - e o Linux sero denotadas dessa - forma. + Ao longo deste artigo as diferenças entre o BSD e o Linux serão destacadas desta forma.     - O que BSD? + O que é o BSD? - BSD significa Distribuio do Sistema - de Berkeley. o nome da - distribuio de cdigos fonte proveniente - da Universidade da Califrnia, Berkeley, as quais foram - originalmente extenses para o sistema operacional &unix; - do departamento de Pesquisas da AT&T. Vrios - projetos de sistemas operacionais de cdigo aberto - so baseados em uma distribuio desse - cdigo fonte, conhecido como 4.4BSD-Lite. Em - adio, tais sistemas constituem-se de - vrias pores de outros projetos de - Cdigo Aberto, incluindo o notvel projeto GNU. A - constituio total do sistema operacional - inclui: + BSD é a sigla para Berkeley Software Distribution. É o nome do código fonte distribuído pela Universidade da Califórnia, Berkeley, que era originalmente uma extensão do UNIX desenvolvido pela área de pesquisa da AT&T. Diversos projetos de sistemas operacionais de código aberto foram baseados em uma versão deste código, conhecido como 4.4BSD-Lite. Além disso, eles incluem vários pacotes de outros projetos de código aberto, com destaque para os do projeto GNU. O sistema operacional geralmente abrange: - O kernel BSD, que cuida do agendamento de processos, - gerenciamento de memria, multi-processamento - simtrico (SMP), dispositivos de controle, - etc. - - Ao contrrio do kernel do Linux, - existem vrios kernels distintos de sistemas BSD - com diferentes caractersticas e - recursos. + O kernel BSD, que lida com o agendamento de processos, gerenciamento de memória, multi processamento simétrico (symmetric multi-processing ou SMP), drivers de dispositivos, etc. A biblioteca C, a API base do sistema. - A biblioteca C do BSD baseada em - cdigo proveniente de Berkeley, e no do - projeto GNU. + A biblioteca C do BSD é baseada no código de Berkeley, não no projeto GNU. - Programas utilitrios como shells, - utilitrios de manuseio de arquivos, compiladores, - linkadores. + Utilitários como shells, gerenciadores de arquivos, compiladores e linkers (conversores de arquivos compilados em executáveis). - Alguns desses programas so derivados - do projeto GNU, outros no. + Alguns utilitários são derivados do projeto GNU, outros não são. - O sistema X Window, que prov uma interface - grfica. + O sistema X Window, que gerencia a interface gráfica. - O sistema X Window usado na maioria das verses - do BSD mantido pelo - projeto X.Org. O &os; permite ao usurio - 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. + O sistema X Window usado na maioria das versões do BSD é mantido pelo Projeto X.Org. O FreeBSD permite ao usuário escolher a partir de uma variedade de ambientes de desktop, tais como o Gnome, KDE, ou Xfce; e gerenciadores gráficos (gerenciadores de janelas) mais leves, como Openbox, Fluxbox, ou Awesome. - Muitos outros programas e utilitrios. + Diversos outros programas e utilitários. - O que um UNIX de verdade? + O que, um verdadeiro <trademark class="registered">UNIX</trademark>? - Os sistemas operacionais BSD no so clones, - mas sim, cdigo livre derivado diretamente do sistema - operacional &unix; da AT&T, que tambm o - ancestral dos modernos &unix; System V. Talvez isso lhe - surpreenda. Como pode ser isso, se a AT&T nunca - disponibilizou seus fontes como cdigo aberto? + Os sistemas operacionais BSD não são cópias ou clones, mas sim derivações de código aberto do sistema operacional UNIX da AT&T, que também é o ancestral do moderno UNIX System V. Isto pode surpreendê-lo. Como isto é possível, uma vez que a AT&T nunca liberou seu código como código aberto? - verdade que o &unix; da AT&T no - Open Source, e do ponto de vista da licena de direitos - legais, o BSD definitivamente no - &unix;, mas por outro lado, a AT&T - importou muito cdigo de outros projetos, especialmente - do Grupo de Pesquisas de Cincias Computacionais (CSRG) da - Universidade da Califrnia, em Berkeley, CA. Desde 1976 - o CSRG lanava fitas magnticas com cpias - de seu software, o qual era chamado de - Distribuio do Software de - Berkeley ou BSD. + É verdade que o UNIX da AT&T não é um sistema de código aberto e no sentido de licenciamento o BSD definitivamente não é UNIX, mas por outro lado a AT&T importou fontes de outros projetos, principalmente do Grupo de Pesquisa de Ciências da Computação (Computer Sciences Research Group ou CSRG) da Universidade da Califórnia em Berkeley, CA. A partir de 1976, o CSRG começou a liberar fitas de seu software, chamando ele de Berkeley Software Distribution ou BSD. - As verses iniciais do BSD consistiam-se - fundamentalmente de programas nvel de - usurio, mas essa realidade mudou dramaticamente assim - que o CSRG fechou um contrato com a Agncia de Pesquisas e - Projetos de Avanados de Defesa (a DARPA) para atualizar - os protocolos de comunicao 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 - implementao amplamente distribuda desses - protocolos eram parte do 4.2BSD, em 1982. + As primeiras distribuições do BSD consistiam principalmente em programas de usuários mas isso mudou radicalmente quando o CSRG firmou um contrato com a Agência de Pesquisa de Projetos de Defesa Avançados (Defense Advanced Research Projects Agency ou DARPA) para atualizar os protocolos de comunicação de sua rede, a ARPANET. Os novos protocolos ficaram conhecidos como Internet Protocols, posteriormente TCP/IP em virtude dos protocolos mais importantes. A primeira implementação amplamente distribuída foi parte do 4.2BSD, em 1982. - Ao longo da dcada de 80, vrias empresas que - produziam estaes de trabalho comearam a - se espalhar. Muitas delas preferiam licenciar o &unix; ao - invs de desenvolverem sistemas operacionais por si - mesmas. A Sun Microsystems em particular, licenciou o &unix; e - implementou uma verso do 4.2BSD, a qual eles chamaram de - &sunos;. Quando a AT&T se deu permisso para vender - o &unix; comercialmente, comearam a desenvolver uma - implementao “na unha” chamada de - System III, que seria rapidamente sucedida pelo System V. A - base do cdigo do System V no inclua o suporte a - networking, ento todas as implementaes - passaram a incluir software adicional do BSD, incluindo o - TCP/IP, e tambm programas utilitrios como o - interpretador de linha de comandos csh e o - editor vi. Em sua coletividade, estes - aprimoramentos foram conhecidos como - Extenses de Berkeley. + Durante a década de 80 surgiram muitas empresas produtoras de estações de trabalho. A maioria preferiu licenciar o UNIX ao invés de desenvolver seus próprios sistemas operacionais. Em particular, a Sun Microsystems licenciou o UNIX e implementou uma versão do 4.2BSD, a qual eles chamaram de SunOS. Quando a própria AT&T começou a comercializar o UNIX, eles começaram com uma implementação de certa forma simples chamada de System III, que logo transformou-se no System V. O código base do System V não incluía comunicação em rede, então todas as implementações incluíram software adicional do BSD, inclusive o software TCP/IP, e também utilitários como o shell csh e o editor vi. Estes aprimoramentos ficaram conhecidos como Berkeley Extensions. - As fitas magnticas do BSD continham cdigo - fonte da AT&T e por isso precisavam de uma licena de - fontes do &unix;. Por volta de 1990, os fundos do CSRG estavam - acabando. Alguns membros do grupo decidiram lanar o - cdigo BSD, que era Open Source, sem o cdigo - proprietrio da AT&T. Finalmente isso aconteceu com - o Networking Tape 2, normalmente conhecido - como Net/2. O Net/2 no era um - sistema operacional completo: aproximadamente 20% do - cdigo do kernel estava faltando. Um dos membros do - CSRG, William F. Jolitz, escreveu o cdigo que faltava e - o lanou 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 lanou uma verso beta de seu - sistema operacional, chamada de BSD/386, baseado nos mesmos - fontes. Depois o nome do sistema operacional mudou para - BSD/OS. + As fitas do BSD continham código fonte da AT&T e portanto necessitavam da licença dos fontes do UNIX. Por volta de 1990, os recursos financeiros do CSRG's estavam acabando, e ele foi encerrado. Alguns membros do grupo decidiram liberar o código do BSD, que era código aberto, sem o código proprietário da AT&T. Isso finalmente aconteceu com a fita Networking Tape 2, também conhecida como Net/2. O Net/2 não era um sistema operacional completo: faltava cerca de 20% do código fonte do kernel. Um dos membros do CSRG, William F. Jolitz, escreveu o código que faltava e o liberou no início de 1992 sob o nome de 386BSD. Ao mesmo tempo, um outro grupo de ex integrantes do CSRG formaram uma empresa comercial chamada Berkeley Software Design Inc. e liberaram uma versão beta de um sistema operacional chamado BSD/386, o qual era baseado nos mesmos fontes. Mais tarde o nome deste sistema operacional foi alterado para BSD/OS. - O 386BSD nunca se tornou um sistema operacional - estvel. Ao invs disso, outros dois projetos - nasceram partir dele, em 1993: O NetBSD e o FreeBSD. Originalmente - os dois projetos divergiram devido s diferenas - quanto pacincia na espera de novas melhorias no - 386BSD: o pessoal do NetBSD comeou o projeto no - incio do ano, e a primeira verso do FreeBSD - no ficou pronta at o final do ano. No meio - tempo, a base do cdigo se modificou o suficiente para - tornar difcil uma unio. Em - adio, 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. + O 386BSD nunca chegou a ser um sistema operacional estável. Ao invés disso, dois outros projetos surgiram a partir dele em 1993: NetBSD e FreeBSD. Este dois projetos divergiam originalmente na questão da espera pelas melhorias no 386BSD: o pessoal do NetBSD iniciou no começo daquele ano, e a primeira versão do FreeBSD não ficou pronta antes do final do ano. Neste meio tempo o código base ficou diferente um do outro o suficiente para tornar difícil sua fusão. Além disso, os projetos tinham objetivos diferentes, como veremos adiante. Em 1996, o OpenBSD surgiu a partir do NetBSD, e em 2003, o DragonFlyBSD surgiu a partir do FreeBSD. - Por qu o BSD no mais - conhecido? + Por que o BSD não é mais conhecido? - Por algumas razes, o BSD relativamente - desconhecido: + Por uma série de razões, o BSD é relativamente desconhecido: - Os desenvolvedores do BSD esto frequentemente - mais interessados em aprimorar seu cdigo do que - fazer propaganda dele. + Os desenvolvedores do BSD estão mais interessados em aprimorar o seu código do que em divulgá-lo. - A maior parte da popularidade do Linux se deve a fatores - externos ao projeto Linux, como a imprensa, e companhias - criadas para oferecer servios em Linux. At - recentemente, os BSDs open source no contavam com - tais proponentes. + Grande parte da popularidade do Linux se deve a fatores externos ao projeto Linux, como a mídia e empresas que foram criadas para prover serviços Linux. Até pouco tempo atrás os BSD de código aberto não tinham este tipo de proposta. - Os desenvolvedores BSD tendem a ser mais experientes do - que desenvolvedores Linux, e tem menos interesse em tornar o - sistema fcil de utilizar. Novatos tendem a se - sentir mais confortveis com Linux. - + Em 1992 a AT&T processou a BSDI, que comercializava o BSD/386, alegando que o produto continha código protegido por direitos autorais da AT&T. O caso foi encerrado fora dos tribunais em 1994, mas o fantasma do litígio continua assombrando. Em março de 2000 um artigo publicado na web afirma que o caso foi recentemente encerrado. - - Em 1992, a AT&T processou a BSDI, vendedora do - BSD/386, alegando que o produto continha cdigo - proprietrio da AT&T. O caso foi resolvido na - corte, em 1994, mas os aspectos da litigao - continuam perseguindo as pessoas. Em Maro 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 - denominao: nos anos 80, os BSD eram - conhecidos como BSD &unix;. Com a - eliminao do ltimo vestgio de - cdigo da AT&T no BSD, ele tambm perdeu o - direito de ser chamado de &unix; Contudo ainda podem ser - vistas referncias em ttulos de livros como - the 4.3BSD &unix; operating system e - the 4.4BSD operating system. + Um detalhe que o processo civil não deixa claro refere-se ao nome: nos anos 80 o BSD era conhecido como BSDUNIX. Com a eliminação dos últimos vestígios do código da AT&T do BSD, ele também perdeu o direito ao nome UNIX. Desta forma você verá referências em livros para o sistema operacional 4.3BSD UNIX e o sistema operacional 4.4BSD. - - - Existe uma idia que os projetos BSD sejam - fragmentados e beligerantes. O Wall - Street Journal falou de - balkanizao nos projetos BSD. - Assim como o processo judicial, essas idias se - baseiam fundamentalmente em histria antiga. - Comparando BSD e Linux - Ento qual realmente a diferena - entre, digamos, o Debian Linux e o FreeBSD? Pra maioria dos - usurios, as diferenas so - surpreendentemente pequenas: Ambos so sistemas - operacionais &unix; like. Ambos so desenvolvidos por - projetos no comerciais ( claro que isso - no se aplica a muitas outras distribuies - Linux). Na prxima seo, vamos dar uma - olhada no BSD e compar-lo com o Linux. As - descries se aplicam mais ao FreeBSD, que - somatiza uma mdia estimada de 80% das - instalaes de sistemas BSD, mas as - diferenas pro NetBSD, pro OpenBSD e pro DragonFlyBSD - so pequenas. + Então, qual é realmente a diferença entre, digamos, o Debian Linux e o FreeBSD? Para a maioria dos usuários, a diferença é surpreendentemente pequena: Ambos são sistemas operacionais estilo UNIX. Ambos são desenvolvidos por projetos não comerciais (isto não se aplica a diversas outras distribuições Linux, é claro). Nas próximas sessões vamos olhar para o BSD e compará-lo ao Linux. As descrições se aplicam principalmente ao FreeBSD, que representa aproximadamente 80% das instalações de BSD, mas as diferenças do NetBSD, OpenBSD e Dragon FlyBSD são pequenas. - Quem dono do BSD? + Quem é o dono do BSD? - Nenhuma pessoa ou corporao dona - do BSD. Ele criado e distribudo por uma - comunidade de contribuidores altamente tcnicos em todo - o mundo. Alguns dos componentes do BSD so projetos - Open Source independentes e gerenciados por mantenedores de - projetos distintos. + Nenhuma pessoa ou empresa é proprietária do BSD. Ele é criado e distribuído por uma comunidade de colaboradores altamente técnica e comprometida espalhada ao redor do mundo. Alguns dos componentes do BSD são projetos de código aberto com seus próprios licenciamentos e gerenciados por diferentes mantenedores. - Como o BSD desenvolvido e atualizado? + Como o BSD é desenvolvido e atualizado? - Os kernels do BSD so desenvolvidos e mantidos - seguindo o modelo de desenvolvimento do Open Source. Cada - projeto mantm uma rvore de - cdigo fonte publicamente acessvel - sob o Sistema de - Verses Concorrentes (CVS), que contm - todos os arquivos fontes do projeto, incluindo - documentao e outros arquivos acidentais. O - CVS permite que usurios faam check - out (em outras palavras, extrair uma cpia) - de qualquer verso desejada do sistema. + Os kernels dos BSDs são desenvolvidos e atualizados seguindo o modelo de desenvolvimento Open Source. Cada projeto mantém uma árvore com código fonte publicamente acessível, que contém todo o código fonte do projeto, incluindo documentação e outros arquivos incidentais. Os usuários podem obter uma cópia completa de qualquer versão. - Um grande nmero de desenvolvedores ao redor do - mundo contribui para as melhorias do BSD. Eles so - divididos em 3 tipos: + Um grande número de desenvolvedores por todo o mundo contribuem com melhorias ao BSD. Eles estão divididos em três categorias: - Contribuidores escrevem - cdigo e documentao. Eles - no tm permisso de commit (adicionar - cdigo) diretamente na rvore de - cdigo fonte. Para que seu cdigo seja - incluso no sistema, necessrio que seja - revisado e aprovado por um desenvolvedor registrado, os - quais so conhecidos como - committer. + Contributors escrevem código ou documentação. Eles não têm permissão para adicionar código diretamente ao repositório principal de código fonte. Para que seu código seja incluído no sistema, ele deve ser revisado e verificado por um desenvolvedor registrado, conhecido como committer. - Committers so - desenvolvedores com acesso de escrita na rvore do - cdigo fonte. Para se tornar um commiter, o - indivduo deve mostrar habilidade na rea em - que ele ativo. + Committers são desenvolvedores com acesso de gravação no repositório principal de código fonte. Para se tornar um committer, um indivíduo deve mostrar habilidade na área em que está ativo. - Faz parte da responsabilidade individual de cada - desenvolvedor considerar quando devem obter - autorizao antes de fazer um commit na - rvore. No geral, desenvolvedores experientes - podem fazer modificaes que so - obviamente corretas sem precisar de consenso. Por - exemplo, um commiter do projeto de - documentao pode corrigir erros - tipogrficos ou gramaticais sem a - necessidade de uma reviso. Por outro lado, - espera-se que desenvolvedores que fazem - alteraes muito abrangentes ou complicadas - enviem suas mudanas para reviso antes de - adicion-las. Em casos extremos, um membro do - Grupo Central (Core Team) cuja funo seja, - o Arquiteto Principal pode ordenar que as - modificaes sejam retiradas da - rvore do cdigo fonte, em um processo - conhecido como backing out. Todos - os desenvolvedores recebem mensagens de correio - eletrnico sobre cada alterao - individual, portanto impossvel fazer - alguma modificao secretamente. + Fica a critério do bom senso individual de cada committer a decisão se eles devem obter ou não um consenso antes de enviar alterações para o repositório de código fonte. Em geral, um committer experiente pode fazer alterações que sejam inquestionavelmente corretas sem obter consenso. Por exemplo, um committer do projeto de documentação pode corrigir erros tipográficos ou gramaticais sem revisão. Por outro lado, espera-se que os desenvolvedores que realizam mudanças complexas ou muito extensas enviem suas alterações para revisão antes de enviá-las para o repositório de código fonte. Em casos extremos, um membro do Core Team com uma função tal como a de arquiteto principal, pode ordenar que as alterações sejam removidas do repositório, num processo conhecido como backing out. Todos os committers recebem emails que descrevem cada commit individual, portanto não é possível enviar alterações para o repositório de código font e em segredo. - 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 no sempre bem - definido. No 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 tm mais voz na hora de dizer as - direes que o projeto deve seguir, do que - outros membros fora do grupo. + O Core Team. O FreeBSD e o NetBSD possuem uma equipe principal (Core team) que gerenciam o projeto. As equipes principais evoluíram ao longo dos projeto e a sua função nem sempre está bem definida. Não é necessário ser um desenvolvedor para ser um membro da equipe principal, embora isto seja normal. As regras para a equipe principal variam de um projeto para o outro, mas no geral elas têm mais voz ativa sobre a direção do projeto do que os demais membros tem. - Esse modelo se diferencia do Linux em inmeras - maneiras: + Esse arranjo difere do Linux de várias maneiras: - No existe uma pessoa em especial que controla - o contedo do sistema. Na prtica, essa - diferena sobretaxada, considerando que o - Arquiteto Principal pode solicitar que cdigos - sejam retirados do sistema, e que at mesmo o - projeto Linux tem vrias pessoas autorizadas a - fazer modificaes. + Ninguém controla o conteúdo do sistema. Na prática, essa diferença é superestimada, uma vez que o arquiteto principal pode exigir que o código seja removido ou substituído, e mesmo no projeto Linux, várias pessoas podem fazer alterações. - Por outro lado, existe um - repositrio central, um lugar nico onde os - fontes inteiros do sistema operacional podem ser - encontrados, incluindo todas as verses - anteriores. + Por outro lado, existe um repositório central, um lugar único no qual você pode encontrar todo o código fonte do sistema operacional, incluindo todas as versões mais antigas. - Os projetos BSD mantm um Sistema - Operacional completo, no apenas o - kernel. Essa distino - marginalmente proveitosa: nem o BSD nem o Linux so - teis sem aplicaes. As - aplicaes usadas sob BSD so - frequentemente as mesmas aplicaes usadas - sob Linux. + Os projetos BSDs mantêm todo o Sistema Operacional, e não apenas o kernel. Essa distinção é apenas marginalmente útil: nem o BSD e nem o Linux são úteis sem aplicativos. Os aplicativos usados no BSD são frequentemente os mesmos aplicativos usados no Linux. - Como resultado da manuteno formalizada - de uma nica rvore CVS do cdigo - fonte, o desenvolvimento do BSD limpo, e - possvel acessar qualquer verso do sistema - por seu nmero de lanamento (release) ou - por data. O CVS ainda oferece manuteno - incremental ao sistema: por exemplo, o repositrio - do FreeBSD atualizado em mdia 100 vezes - por dia. A maioria dessas alteraes - de pequena ordem. + Como resultado da manutenção formal de um único repositório SVN com o código fonte, o desenvolvimento do BSD é claro e é possível acessar qualquer versão do sistema por número de release ou por data. O SVN também permite atualizações incrementais no sistema: por exemplo, o repositório do FreeBSD é atualizado cerca de 100 vezes por dia. A maioria dessas mudanças é pequena. - Releases BSD + Releases do BSD - O FreeBSD, o NetBSD e o OpenBSD oferecem o sistema em - trs verses (releases) - diferentes. Como no Linux, os releases so - identificados por um nmero, como 1.4.1 ou 3.5. Em - adio, o nmero da verso tem - um sufixo, indicando seu propsito: + O FreeBSD, o NetBSD e o OpenBSD fornecem o sistema em três diferentes releases. Como no Linux, os releases recebem um número como 1.4.1 ou 3.5. Além disso, o número da versão tem um sufixo indicando sua finalidade: - A verso de desenvolvimento do sistema - chamada de CURRENT. O FreeBSD - relaciona um nmero ao CURRENT, por exemplo, FreeBSD - 5.0-CURRENT. O NetBSD usa um esquema de - denominao um pouco diferente, adicionando - um sufixo com uma letra nica que indica - modificaes nas interfaces internas, por - exemplo NetBSD 1.4.3G. O OpenBSD no adiciona - nmeros (OpenBSD-current). Todo - novo desenvolvimento no sistema vai nesse branch. + A versão de desenvolvimento do sistema é chamada de CURRENT. O FreeBSD atribui um número a CURRENT, por exemplo, FreeBSD 5.0-CURRENT. O NetBSD usa um esquema de nomenclatura ligeiramente diferente e acrescenta um sufixo de uma única letra que indica mudanças nas interfaces internas, por exemplo, o NetBSD 1.4.3G. O OpenBSD não atribui um número (OpenBSD-current). Todo novo desenvolvimento no sistema entra neste branch. - Em intervalos regulares, entre duas a quatro vezes por - ano, os projetos lanam uma nova verso de - RELEASE do sistema, que - disponibilizado em CD-ROM e por download gratuto - em stios de FTP, por exemplo OpenBSD 2.6-RELEASE - ou NetBSD 1.4-RELEASE. A verso do RELEASE - destinada a usurios finais e a - verso normal do sistema. O NetBSD oferece ainda - patch releases (releases de - correes) com um terceiro dgito, - por exemplo, NetBSD 1.4.2. + Em intervalos regulares, entre duas e quatro vezes por ano, os projetos lançam uma versão RELEASE do sistema, a qual é disponibilizada por meio de CD-ROMs e por meio de download gratuito em sites FTP, por exemplo, OpenBSD 2.6-RELEASE ou NetBSD 1.4-RELEASE. A versão RELEASE destina-se a usuários finais e é a versão normal do sistema. O NetBSD também fornece versões de correção (Patch Releases) com um terceiro dígito, por exemplo, o NetBSD 1.4.2. - Conforme os problemas so encontrados em uma - verso RELEASE, eles so corrigidos, e as - correes so adicionadas - rvore CVS. No FreeBSD a verso resultante - chamada de STABLE, - enquanto que no NetBSD e no OpenBSD elas continuam sendo - chamadas de verso RELEASE. Novas - caractersticas menores tambm podem ser - adicionadas nesse branch depois do perodo de - testes no CURRENT. + A medida que os erros são encontrados em uma versão RELEASE, eles são corrigidos e as correções são adicionadas ao repositório SVN. No FreeBSD, a versão resultante é chamada de STABLE, enquanto no NetBSD e OpenBSD continua sendo chamada de versão RELEASE. Novos recursos menores também podem ser adicionados a essa branch após um período de teste na branch CURRENT. Patches de segurança e outras correções de bugs importantes também são aplicadas a todas as versões RELEASE suportadas. - Em contraste, o Linux mantm duas - rvores de cdigo separadas: a verso - estvel e a verso de desenvolvimento. A - verso estvel tem ainda um nmero - menor de verso, como 2.0, 2.2 ou 2.4. Verses - em desenvolvimento tem o nmero menor mpar, - como 2.1, 2.4 e 2.5. Em cada caso, a verso - ainda seguida de um nmero posterior designando o - release exato. Em adio, cada vendedor de - Linux coloca suas prprias aplicaes e - utilitrios nvel de usurio, - portanto o nome de sua distribuio - tambm importante. Cada - distribuio do vendedor ainda - acrescida de seu prprio nmero, ento - a descrio completa seria algo parecido com - TurboLinux 6.0 com kernel - 2.2.14 + Por outro lado, o Linux mantém duas árvores de código separadas: a versão estável e a versão de desenvolvimento. Versões estáveis têm um número de versão menor par, como por exemplo 2.0, 2.2 ou 2.4. Versões de desenvolvimento têm um número de versão menor ímpar, como por exemplo 2.1, 2.3 ou 2.5. Em cada caso, o número é seguido por um outro número que designa a release exata. Além disso, cada fornecedor adiciona seus próprios programas e utilitários de área de usuário, portanto, o nome da distribuição também é importante. Cada fornecedor de distribuição também atribui números de versão à distribuição, portanto, uma descrição completa seria algo como TurboLinux 6.0 com kernel 2.2.14 . - Quais so as verses disponveis do - BSD? + Quais versões do BSD estão disponíveis? - Em contraste com as numerosas distribuies - Linux, existem apenas quatro BSDs de cdigo livre. - Cada projeto BSD mantm sua prpria - rvore de cdigo fonte e seu prprio - kernel. Na prtica, as divergncias entre o - cdigo nvel de usurio parece - ser ainda menor entre os projetos BSD do que entre os - vrios Linux. + Em contraste com as numerosas distribuições do Linux, existem apenas quatro grandes distribuições BSD de código aberto. Cada projeto BSD mantém seu próprio repositório de código fonte e o seu próprio kernel. Porém na prática, parece haver menos divergências do código entre os projetos BSD do que no Linux. - difcil categorizar os objetivos de cada - projeto: as diferenas so bastante subjetivas. - Basicamente, + É difícil categorizar os objetivos de cada projeto: as diferenças são muito subjetivas. Basicamente, - O FreeBSD clama por alta performance e facilidade de - uso para usurios finais, e o favorito de - provedores de contedo da rede mundial de - computadores. Ele pode ser usado em um grande - nmero 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 - especificao NEC PC-98. O projeto &os; - possui significativamente mais usurios do que - os outros projetos. + O FreeBSD visa o alto desempenho e a facilidade de uso pelos usuários finais, e é um dos favoritos dos provedores de conteúdo da web. Ele pode ser executado em diversas plataformas e tem significativamente mais usuários do que os outros projetos. + - O NetBSD clama pelo mximo de portabilidade: - lgico que roda NetBSD. Ele - roda de mquinas palmtop grandes - servidores, e vem sendo usado at em misses - espaciais da NASA. particularmente uma boa - escolha para rodar em equipamentos antigos que no - sejam &intel;. + O NetBSD visa a máxima portabilidade: é claro que roda o NetBSD. Ele pode ser executado em diversas plataformas de hardware, de palmtops até grandes servidores, e até mesmo já foi usado em missões espaciais da NASA. É uma escolha particularmente boa para rodar em hardware antigo que não seja Intel. - O OpenBSD clama por segurana e pureza de - cdigo: ele usa uma combinao dos - conceitos de cdigo livre com rigorosas - revises de seu cdigo para criar um sistema - demonstravelmente correto, tornando-o a escolha de - organizaes conscientes com a - segurana como bancos e departamentos do governo. - Como o NetBSD, ele roda em vrias - plataformas. + O OpenBSD visa a segurança e a pureza de código: ele usa uma combinação do conceito de código aberto ao de revisões rigorosas de código para criar um sistema que seja comprovadamente correto, tornando-o a escolha preferida de organizações preocupadas com segurança, tais como bancos, bolsas de valores e departamentos do governo dos EUA. Tal como o NetBSD, ele pode ser executado em várias plataformas. - O DragonFlyBSD clama por alta performance e - escalabilidade acima de tudo, no importa se estamos - falando de um sistema composto por um nico n - ou um sistema massivamente clusterizado. O DragonFlyBSD tem - muitos objetivos tcnicos de longo prazo, mas o seu - foco concentra-se em prover uma infra estrutura de SMP - (multiprocessamento simtrico) que seja fcil - de entender, manter e desenvolver. + O DragonFlyBSD tem como objetivo o alto desempenho e a escalabilidade sob todos os aspectos, desde um sistema de um único nó até um sistema altamente clusterizado. O DragonFlyBSD tem várias metas técnicas de longo prazo, mas o foco está em fornecer uma infraestrutura compatível com SMP que seja fácil de entender, manter e desenvolver. - Existem ainda dois sistemas operacionais BSD &unix; - adicionais que no so de cdigo livre, - o BSD/OS e o &macos; X da Apple: + Também existem dois sistemas operacionais BSD UNIX que não são de código aberto, o BSD/OS e Mac OS X da Apple: - O BSD/OS era o mais velho dos derivados do 4.4BSD. - Ele no era de cdigo livre, embora as - licenas de seu cdigo fonte estivessem - disponveis por um preo relativamente - baixo. Ele assemelhava-se ao FreeBSD de diversas formas. - Dois anos depois da aquisio da BSDI pela - Wind River Systems, o BSD/OS falhou em sobreviver como um - produto independente. O suporte e o cdigo fonte - podem ainda estar disponveis pela Wind River, mas - os novos desenvolvimentos esto todos focados no - sistema operacional embarcado VxWorks. + O BSD/OS foi o mais antigo dos sistemas derivados do 4.4BSD. Não era um sistema de código aberto, embora as licenças do código-fonte estivessem disponíveis a um custo relativamente baixo. Assemelhava-se ao FreeBSD de várias maneiras. Dois anos após a aquisição da BSDi pela Wind River Systems, o BSD/OS não conseguiu sobreviver como um produto independente. O suporte e o código-fonte ainda podem estar disponíveis por parte da Wind River, mas todo desenvolvimento novo está focado no sistema operacional embarcado VxWorks. - O - &macos; X a mais recente verso do - sistema operacional da linha &macintosh; da Apple Computers Inc. - O core BSD deste sistema operacional, o Darwin, - est disponvel como um sistema operacional - completamente funcional para computadores x86 e PPC. - Contudo, o sistema grfico Aqua/Quartz e muitos - outros aspectos proprietrios do &macos; X - continuam como cdigo fechado. Vrios - desenvolvedores do Darwin tambm so - desenvolvedores do &os; e vice versa. + O Mac OS X é a versão mais recente do sistema operacional para os equipamentos Mac da Apple. O núcleo BSD deste sistema operacional, Darwin, está disponível como um sistema operacional de código aberto totalmente funcional para computadores x86 e PPC. No entanto, o sistema gráfico Aqua/Quartz e muitos outros aspectos proprietários do Mac OS X continuam fechados. Vários desenvolvedores do Darwin também são committers do FreeBSD, e vice-versa. - Como a licena BSD se diferencia da licena - Pblica GNU? + Como a licença BSD difere da licença GNU Publica? - O Linux est disponvel sob a Licena - Pblica Geral GPL (GPL), que foi planejada - para eliminar o software proprietrio (de fonte - fechada). Em particular, qualquer trabalho derivado de um - produto lanado sob a GPL tambm deve oferecer - seu cdigo fonte, caso seja requerido. Em contraste, a - licena - BSD menos restritiva: - distribuies apenas binrias so - permitidas. Isso particularmente atrativo para - aplicaes acopladas (embedded). + O Linux está disponível sob a Licença Pública Geral GNU (GPL), que é projetada para eliminar o software de código fechado. Em particular, qualquer trabalho derivado de um produto lançado sob a GPL também deve ser fornecido com o código fonte, se solicitado. Por outro lado, a licença BSD é menos restritiva: é permitida a distribuição somente dos binários. O que é particularmente atraente para aplicativos embarcados. O que mais eu deveria saber? - Considerando que um nmero menor de - aplicaes est disponvel 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 - modificaes no kernel, de forma a possibilitar - as corretas chamadas de sistemas Linux, e arquivos de - compatibilidade Linux, como a biblioteca C. No existe - diferena notvel na velocidade de - execuo entre aplicaes Linux - rodando em uma mquina Linux e aplicaes - Linux rodando em uma mquina BSD de mesma - velocidade. + Como menos aplicativos estão disponíveis para o BSD do que para o Linux, os desenvolvedores do BSD criaram um pacote de compatibilidade com o Linux, o qual permite que os programas Linux sejam executados sob o BSD. O pacote inclui tanto as modificações do kernel, necessárias para executar corretamente as chamadas do sistema Linux e quanto os arquivos de compatibilidade do Linux, como a biblioteca C. Não há diferença perceptível na velocidade de execução entre um aplicativo Linux em execução em uma máquina Linux nativa e um aplicativo Linux em execução em uma máquina BSD, contanto que ambas tenham o mesmo hardware. - A natureza tudo do mesmo fornecedor dos - sistemas BSD implica na maior facilidade de - atualizao do que frequentemente acontece no - caso do Linux. Os BSD oferecem atualizaes de - verses de bibliotecas oferecendo mdulos de - compatibilidade com verses mais antigas de - bibliotecas, dessa forma possvel rodar - binrios que existem h vrios anos sem o - menor problema. + A natureza do BSD de ser um sistema em que tudo é provido por um único fornecedor significa que as atualizações são muito mais fáceis de se lidar do que frequentemente ocorre no caso no Linux. O BSD lida com as atualizações das versões das bibliotecas fornecendo módulos de compatibilidade para as versões anteriores, portanto, é possível executar binários bastante antigos sem problemas. - Qual eu devo usar, BSD ou Linux? + Qual devo usar, BSD ou Linux? - O que isso tudo significa na prtica? Quem deve - usar BSD? Quem deve usar Linux? + O que tudo isso significa na prática? Quem deve usar o BSD, quem deve usar o Linux? - Essa uma pergunta muito difcil para se - responder. Aqui esto algumas - consideraes: + Esta é uma pergunta muito difícil de responder. Aqui estão algumas diretrizes: - Se no est quebrado, no - conserte: Se voc j usa algum - sistema operacional de cdigo livre, e est - feliz com ele, provavelmente no existe uma boa - razo para mudar. + Se não está quebrado, não conserte: Se você já usa um sistema operacional de código aberto e está feliz com ele, provavelmente não existe nenhuma razão para mudar. - Sistemas BSD, em particular o FreeBSD, podem ter - performance notavelmente superior ao Linux. Mas - isso no uma regra. Em muitos casos a - diferena pode ser pouca ou at mesmo nem - existir. Em alguns casos o Linux pode funcionar melhor - que o FreeBSD. + Os sistemas BSD, em particular o FreeBSD, podem ter um desempenho notavelmente superior ao Linux. Mas isto não é uma verdade absoluta. Em muitos casos, há pouca ou nenhuma diferença no desempenho. E em alguns casos, o Linux pode ter um desempenho melhor que o FreeBSD. - No geral, sistemas BSD tem melhor - reputao por sua confiabilidade, - principalmente por ser resultado de uma base de - cdigos mais madura. + Em geral, os sistemas BSD têm a reputação de oferecer uma melhor confiabilidade, principalmente como resultado de ter uma base de código mais madura. - Os projetos BSD tm uma melhor - reputao em relao a - qualidade e abrangncia da sua - documentao. Os vrios projetos de - documentao tm por objetivo prover - ativamente documentos atualizados, em muitos idiomas e - cobrindo todos os aspectos do sistema. + Os projetos BSD têm uma reputação melhor pela qualidade e completude da sua documentação. Os vários projetos de documentação visam fornecer uma documentação que é atualizada constantemente, disponibilizada em muitos idiomas, e que cobre todos os aspectos do sistema. - - A licena BSD pode ser mais atrativa do que a - GPL. - + A licença BSD pode ser mais atraente que a GPL. - O BSD pode executar a maioria dos binrios do - Linux, enquanto o Linux no pode executar - binrios do BSD. Muitas das - implementaes; BSD podem inclusive executar - binrios de outros sistemas derivados do &unix;. - Como resultado, o BSD pode ser uma opo de - migrao a partir de outros sistemas mais - fcil do que o Linux seria. + O BSD pode executar a maioria dos binários do Linux, já o Linux por sua vez não pode executar binários do BSD. Muitas implementações do BSD também podem executar binários de outros sistemas semelhantes ao UNIX. Como resultado, pode ser mais fácil migrar de outros sistemas para o BSD do que seria migrar para o Linux. - Quem oferece suporte, servios e treinamento para - o BSD? + Quem fornece suporte, serviços e treinamento para o BSD? - A BSDI / FreeBSD - Mall, Inc. tm fornecido contratos de suporte - FreeBSD no mercado a quase uma dcada. - - Em adio, cada um dos projetos tem uma - lista de consultores que podem ser contratados: FreeBSD, - NetBSD, - e OpenBSD. + A BSDi / FreeBSD Mall, Inc. fornece contratos de suporte para o FreeBSD já há quase uma década. + + Além disso, o website de cada um dos projetos possui uma lista de consultores disponíveis para contratação: FreeBSD, NetBSD, and OpenBSD.
    Added: head/pt_BR.ISO8859-1/articles/explaining-bsd/pt_BR.po ============================================================================== --- /dev/null 00:00:00 1970 (empty, because file is newly added) +++ head/pt_BR.ISO8859-1/articles/explaining-bsd/pt_BR.po Thu Aug 30 11:06:48 2018 (r52193) @@ -0,0 +1,1137 @@ +# $FreeBSD$ +# Danilo G. Baio , 2018. #zanata +# Edson Brandi , 2018. #zanata +# Rafael Mentz Aquino , 2018. #zanata +msgid "" +msgstr "" +"Project-Id-Version: PACKAGE VERSION\n" +"POT-Creation-Date: 2018-08-29 00:38+0000\n" +"PO-Revision-Date: 2018-08-28 11:30+0000\n" +"Last-Translator: Edson Brandi \n" +"Language-Team: Portuguese (Brazil)\n" +"Language: pt_BR\n" +"MIME-Version: 1.0\n" +"Content-Type: text/plain; charset=UTF-8\n" +"Content-Transfer-Encoding: 8bit\n" +"X-Generator: Zanata 4.6.2\n" +"Plural-Forms: nplurals=2; plural=(n != 1)\n" + +#. Put one translator per line, in the form NAME , YEAR1, YEAR2 +msgctxt "_" +msgid "translator-credits" +msgstr "" +"Edson Brandi, ebrandi@FreeBSD.org, 2018\n" +"Rafael Mentz Aquino, rafael@lk6.com.br, 2018" + +#. (itstool) path: info/title +#: article.translate.xml:7 +msgid "Explaining BSD" +msgstr "Explicando o BSD" + +#. (itstool) path: affiliation/address +#: article.translate.xml:10 +#, no-wrap +msgid "grog@FreeBSD.org" +msgstr "grog@FreeBSD.org" + +#. (itstool) path: info/author +#: article.translate.xml:9 +msgid "" +"GregLehey <_:address-1/> " +msgstr "" +"GregLehey <_:address-1/> " + +#. (itstool) path: legalnotice/para +#: article.translate.xml:14 +msgid "FreeBSD is a registered trademark of the FreeBSD Foundation." +msgstr "FreeBSD is a registered trademark of the FreeBSD Foundation." + +#. (itstool) path: legalnotice/para +#: article.translate.xml:16 +msgid "" +"AMD, AMD Athlon, AMD Opteron, AMD Phenom, AMD Sempron, AMD Turion, Athlon, " +"Élan, Opteron, and PCnet are trademarks of Advanced Micro Devices, Inc." +msgstr "" +"AMD, AMD Athlon, AMD Opteron, AMD Phenom, AMD Sempron, AMD Turion, Athlon, " +"Élan, Opteron, and PCnet are trademarks of Advanced Micro Devices, Inc." + +#. (itstool) path: legalnotice/para +#: article.translate.xml:19 +msgid "" +"Apple, AirPort, FireWire, iMac, iPhone, iPad, Mac, Macintosh, Mac OS, " +"Quicktime, and TrueType are trademarks of Apple Inc., registered in the U.S. " +"and other countries." +msgstr "" +"Apple, AirPort, FireWire, iMac, iPhone, iPad, Mac, Macintosh, Mac OS, " +"Quicktime, and TrueType are trademarks of Apple Inc., registered in the U.S. " +"and other countries." + +#. (itstool) path: legalnotice/para +#: article.translate.xml:24 +msgid "" +"Intel, Celeron, Centrino, Core, EtherExpress, i386, i486, Itanium, Pentium, " +"and Xeon are trademarks or registered trademarks of Intel Corporation or its " +"subsidiaries in the United States and other countries." +msgstr "" +"Intel, Celeron, Centrino, Core, EtherExpress, i386, i486, Itanium, Pentium, " +"and Xeon are trademarks or registered trademarks of Intel Corporation or its " +"subsidiaries in the United States and other countries." + +#. (itstool) path: legalnotice/para +#: article.translate.xml:28 +msgid "Linux is a registered trademark of Linus Torvalds." +msgstr "Linux is a registered trademark of Linus Torvalds." + +#. (itstool) path: legalnotice/para +#: article.translate.xml:30 +msgid "" +"Motif, OSF/1, and UNIX are registered trademarks and IT DialTone and The " +"Open Group are trademarks of The Open Group in the United States and other " +"countries." +msgstr "" +"Motif, OSF/1, and UNIX are registered trademarks and IT DialTone and The " +"Open Group are trademarks of The Open Group in the United States and other " +"countries." + +#. (itstool) path: legalnotice/para +#: article.translate.xml:34 +msgid "" +"SPARC, SPARC64, and UltraSPARC are trademarks of SPARC International, Inc in " +"the United States and other countries. SPARC International, Inc owns all of " +"the SPARC trademarks and under licensing agreements allows the proper use of " +"these trademarks by its members." +msgstr "" +"SPARC, SPARC64, and UltraSPARC are trademarks of SPARC International, Inc in " +"the United States and other countries. SPARC International, Inc owns all of " +"the SPARC trademarks and under licensing agreements allows the proper use of " +"these trademarks by its members." + +#. (itstool) path: legalnotice/para +#: article.translate.xml:39 +msgid "" +"Sun, Sun Microsystems, Java, Java Virtual Machine, JDK, JRE, JSP, JVM, " +"Netra, OpenJDK, Solaris, StarOffice, SunOS and VirtualBox are trademarks or " +"registered trademarks of Sun Microsystems, Inc. in the United States and " +"other countries." +msgstr "" +"Sun, Sun Microsystems, Java, Java Virtual Machine, JDK, JRE, JSP, JVM, " +"Netra, OpenJDK, Solaris, StarOffice, SunOS and VirtualBox are trademarks or " +"registered trademarks of Sun Microsystems, Inc. in the United States and " +"other countries." + +#. (itstool) path: legalnotice/para +#: article.translate.xml:44 +msgid "" +"UNIX is a registered trademark of The Open Group in the United States and " +"other countries." +msgstr "" +"UNIX is a registered trademark of The Open Group in the United States and " +"other countries." + +#. (itstool) path: legalnotice/para +#: article.translate.xml:46 +msgid "" +"Many of the designations used by manufacturers and sellers to distinguish " +"their products are claimed as trademarks. Where those designations appear in " +"this document, and the FreeBSD Project was aware of the trademark claim, the " +"designations have been followed by the ™ or the ® symbol." +msgstr "" +"Many of the designations used by manufacturers and sellers to distinguish " +"their products are claimed as trademarks. Where those designations appear in " +"this document, and the FreeBSD Project was aware of the trademark claim, the " +"designations have been followed by the ™ or the ® symbol." + +#. (itstool) path: info/pubdate +#. (itstool) path: info/releaseinfo +#: article.translate.xml:54 article.translate.xml:56 +msgid "" +"$FreeBSD: head/en_US.ISO8859-1/articles/explaining-bsd/article.xml 51926 " +"2018-06-29 07:33:14Z eadler $" +msgstr "" +"$FreeBSD: head/en_US.ISO8859-1/articles/explaining-bsd/article.xml 51926 " +"2018-06-29 07:33:14Z eadler $" + +#. (itstool) path: abstract/para +#: article.translate.xml:59 +msgid "" +"In the open source world, the word Linux is almost synonymous " +"with Operating System, but it is not the only open source " +"UNIX operating system." *** DIFF OUTPUT TRUNCATED AT 1000 LINES *** From owner-svn-doc-head@freebsd.org Thu Aug 30 20:44:28 2018 Return-Path: Delivered-To: svn-doc-head@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id F1C4CEF885B; Thu, 30 Aug 2018 20:44:27 +0000 (UTC) (envelope-from jkois@FreeBSD.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mxrelay.nyi.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 81900720F9; Thu, 30 Aug 2018 20:44:27 +0000 (UTC) (envelope-from jkois@FreeBSD.org) Received: from repo.freebsd.org (repo.freebsd.org [IPv6:2610:1c1:1:6068::e6a:0]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 3214E119A7; Thu, 30 Aug 2018 20:44:27 +0000 (UTC) (envelope-from jkois@FreeBSD.org) Received: from repo.freebsd.org ([127.0.1.37]) by repo.freebsd.org (8.15.2/8.15.2) with ESMTP id w7UKiQPr077467; Thu, 30 Aug 2018 20:44:26 GMT (envelope-from jkois@FreeBSD.org) Received: (from jkois@localhost) by repo.freebsd.org (8.15.2/8.15.2/Submit) id w7UKiQLu077466; Thu, 30 Aug 2018 20:44:26 GMT (envelope-from jkois@FreeBSD.org) Message-Id: <201808302044.w7UKiQLu077466@repo.freebsd.org> X-Authentication-Warning: repo.freebsd.org: jkois set sender to jkois@FreeBSD.org using -f From: Johann Kois Date: Thu, 30 Aug 2018 20:44:26 +0000 (UTC) To: doc-committers@freebsd.org, svn-doc-all@freebsd.org, svn-doc-head@freebsd.org Subject: svn commit: r52194 - head/de_DE.ISO8859-1/share/xml X-SVN-Group: doc-head X-SVN-Commit-Author: jkois X-SVN-Commit-Paths: head/de_DE.ISO8859-1/share/xml X-SVN-Commit-Revision: 52194 X-SVN-Commit-Repository: doc MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-BeenThere: svn-doc-head@freebsd.org X-Mailman-Version: 2.1.27 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: Thu, 30 Aug 2018 20:44:28 -0000 Author: jkois Date: Thu Aug 30 20:44:26 2018 New Revision: 52194 URL: https://svnweb.freebsd.org/changeset/doc/52194 Log: r52055 -> r52189 MFde: Resnyc de/share/xml/news.xml Modified: head/de_DE.ISO8859-1/share/xml/news.xml Modified: head/de_DE.ISO8859-1/share/xml/news.xml ============================================================================== --- head/de_DE.ISO8859-1/share/xml/news.xml Thu Aug 30 11:06:48 2018 (r52193) +++ head/de_DE.ISO8859-1/share/xml/news.xml Thu Aug 30 20:44:26 2018 (r52194) @@ -4,7 +4,7 @@