The translation is temporarily closed for contributions due to maintenance, please come back later.

Translation

(itstool) path: sect2/para
English
No one person or corporation owns BSD. It is created and distributed by a community of highly technical and committed contributors all over the world. Some of the components of BSD are Open Source projects in their own right and managed by different project maintainers.
309/2700 · 270
Context English Portuguese (Brazil) State
The BSD operating systems are not clones, but open source derivatives of AT&amp;T's Research <trademark class="registered">UNIX</trademark> operating system, which is also the ancestor of the modern <trademark class="registered">UNIX</trademark> System V. This may surprise you. How could that happen when AT&amp;T has never released its code as open source? Os sistemas operacionais BSD não são cópias ou clones, mas sim derivações de código aberto do sistema operacional <trademark class="registered">UNIX</trademark> da AT&amp;T, que também é o ancestral do moderno <trademark class="registered">UNIX</trademark> System V. Isto pode surpreendê-lo. Como isto é possível, uma vez que a AT&amp;T nunca liberou seu código como código aberto?
It is true that AT&amp;T <trademark class="registered">UNIX</trademark> is not open source, and in a copyright sense BSD is very definitely <emphasis>not</emphasis> <trademark class="registered">UNIX</trademark>, but on the other hand, AT&amp;T has imported sources from other projects, noticeably the Computer Sciences Research Group (CSRG) of the University of California in Berkeley, CA. Starting in 1976, the CSRG started releasing tapes of their software, calling them <emphasis>Berkeley Software Distribution</emphasis> or <emphasis>BSD</emphasis>. É verdade que o <trademark class="registered">UNIX</trademark> da AT&amp;T não é um sistema de código aberto e no sentido de licenciamento o BSD definitivamente <emphasis>não é</emphasis> <trademark class="registered">UNIX</trademark>, mas por outro lado a AT&amp;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 <emphasis>Berkeley Software Distribution</emphasis> ou <emphasis>BSD</emphasis>.
Initial BSD releases consisted mainly of user programs, but that changed dramatically when the CSRG landed a contract with the Defense Advanced Research Projects Agency (DARPA) to upgrade the communications protocols on their network, ARPANET. The new protocols were known as the <emphasis>Internet Protocols</emphasis>, later <emphasis>TCP/IP</emphasis> after the most important protocols. The first widely distributed implementation was part of 4.2BSD, in 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 <emphasis>Internet Protocols</emphasis>, posteriormente <emphasis>TCP/IP</emphasis> em virtude dos protocolos mais importantes. A primeira implementação amplamente distribuída foi parte do 4.2BSD, em 1982.
In the course of the 1980s, a number of new workstation companies sprang up. Many preferred to license <trademark class="registered">UNIX</trademark> rather than developing operating systems for themselves. In particular, Sun Microsystems licensed <trademark class="registered">UNIX</trademark> and implemented a version of 4.2BSD, which they called <trademark>SunOS</trademark>. When AT&amp;T themselves were allowed to sell <trademark class="registered">UNIX</trademark> commercially, they started with a somewhat bare-bones implementation called System III, to be quickly followed by System V. The System V code base did not include networking, so all implementations included additional software from the BSD, including the TCP/IP software, but also utilities such as the <emphasis>csh</emphasis> shell and the <emphasis>vi</emphasis> editor. Collectively, these enhancements were known as the <emphasis>Berkeley Extensions</emphasis>. Durante a década de 80 surgiram muitas empresas produtoras de estações de trabalho. A maioria preferiu licenciar o <trademark class="registered">UNIX</trademark> ao invés de desenvolver seus próprios sistemas operacionais. Em particular, a Sun Microsystems licenciou o <trademark class="registered">UNIX</trademark> e implementou uma versão do 4.2BSD, a qual eles chamaram de <trademark>SunOS</trademark>. Quando a própria AT&amp;T começou a comercializar o <trademark class="registered">UNIX</trademark>, 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 <emphasis>csh</emphasis> e o editor <emphasis>vi</emphasis>. Estes aprimoramentos ficaram conhecidos como <emphasis>Berkeley Extensions</emphasis>.
The BSD tapes contained AT&amp;T source code and thus required a <trademark class="registered">UNIX</trademark> source license. By 1990, the CSRG's funding was running out, and it faced closure. Some members of the group decided to release the BSD code, which was Open Source, without the AT&amp;T proprietary code. This finally happened with the <emphasis>Networking Tape 2</emphasis>, usually known as <emphasis>Net/2</emphasis>. Net/2 was not a complete operating system: about 20% of the kernel code was missing. One of the CSRG members, William F. Jolitz, wrote the remaining code and released it in early 1992 as <emphasis>386BSD</emphasis>. At the same time, another group of ex-CSRG members formed a commercial company called <link xlink:href="http://www.bsdi.com/">Berkeley Software Design Inc.</link> and released a beta version of an operating system called <link xlink:href="http://www.bsdi.com/">BSD/386</link>, which was based on the same sources. The name of the operating system was later changed to BSD/OS. As fitas do BSD continham código fonte da AT&amp;T e portanto necessitavam da licença dos fontes do <trademark class="registered">UNIX</trademark>. 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&amp;T. Isso finalmente aconteceu com a fita <emphasis>Networking Tape 2</emphasis>, também conhecida como <emphasis>Net/2</emphasis>. 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 <emphasis>386BSD</emphasis>. Ao mesmo tempo, um outro grupo de ex integrantes do CSRG formaram uma empresa comercial chamada <link xlink:href="http://www.bsdi.com/">Berkeley Software Design Inc.</link> e liberaram uma versão beta de um sistema operacional chamado <link xlink:href="http://www.bsdi.com/">BSD/386</link>, o qual era baseado nos mesmos fontes. Mais tarde o nome deste sistema operacional foi alterado para BSD/OS.
386BSD never became a stable operating system. Instead, two other projects split off from it in 1993: <link xlink:href="http://www.NetBSD.org/">NetBSD</link> and <link xlink:href="@@URL_RELPREFIX@@/index.html">FreeBSD</link>. The two projects originally diverged due to differences in patience waiting for improvements to 386BSD: the NetBSD people started early in the year, and the first version of FreeBSD was not ready until the end of the year. In the meantime, the code base had diverged sufficiently to make it difficult to merge. In addition, the projects had different aims, as we will see below. In 1996, <link xlink:href="http://www.OpenBSD.org/">OpenBSD</link> split off from NetBSD, and in 2003, <link xlink:href="http://www.dragonflybsd.org/">DragonFlyBSD</link> split off from 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: <link xlink:href="http://www.NetBSD.org/">NetBSD</link> e <link xlink:href="@@URL_RELPREFIX@@/index.html">FreeBSD</link>. 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 <link xlink:href="http://www.OpenBSD.org/">OpenBSD</link> surgiu a partir do NetBSD, e em 2003, o <link xlink:href="http://www.dragonflybsd.org/">DragonFlyBSD</link> surgiu a partir do FreeBSD.
Why is BSD not better known? Por que o BSD não é mais conhecido?
For a number of reasons, BSD is relatively unknown: Por uma série de razões, o BSD é relativamente desconhecido:
The BSD developers are often more interested in polishing their code than marketing it. Os desenvolvedores do BSD estão mais interessados em aprimorar o seu código do que em divulgá-lo.
Much of Linux's popularity is due to factors external to the Linux projects, such as the press, and to companies formed to provide Linux services. Until recently, the open source BSDs had no such proponents. 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.
In 1992, AT&amp;T sued <link xlink:href="http://www.bsdi.com/">BSDI</link>, the vendor of BSD/386, alleging that the product contained AT&amp;T-copyrighted code. The case was settled out of court in 1994, but the spectre of the litigation continues to haunt people. In March 2000 an article published on the web claimed that the court case had been <quote>recently settled</quote>. Em 1992 a AT&amp;T processou a <link xlink:href="http://www.bsdi.com/">BSDI</link>, que comercializava o BSD/386, alegando que o produto continha código protegido por direitos autorais da AT&amp;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 <quote>recentemente encerrado</quote>.
One detail that the lawsuit did clarify is the naming: in the 1980s, BSD was known as <quote>BSD <trademark class="registered">UNIX</trademark></quote>. With the elimination of the last vestige of AT&amp;T code from BSD, it also lost the right to the name <trademark class="registered">UNIX</trademark>. Thus you will see references in book titles to <quote>the 4.3BSD <trademark class="registered">UNIX</trademark> operating system</quote> and <quote>the 4.4BSD operating system</quote>. Um detalhe que o processo civil não deixa claro refere-se ao nome: nos anos 80 o BSD era conhecido como <quote>BSD<trademark class="registered">UNIX</trademark></quote>. Com a eliminação dos últimos vestígios do código da AT&amp;T do BSD, ele também perdeu o direito ao nome <trademark class="registered">UNIX</trademark>. Desta forma você verá referências em livros para o <quote>sistema operacional 4.3BSD <trademark class="registered">UNIX</trademark></quote> e o <quote>sistema operacional 4.4BSD</quote>.
Comparing BSD and Linux Comparando BSD e Linux
So what is really the difference between, say, Debian Linux and FreeBSD? For the average user, the difference is surprisingly small: Both are <trademark class="registered">UNIX</trademark> like operating systems. Both are developed by non-commercial projects (this does not apply to many other Linux distributions, of course). In the following section, we will look at BSD and compare it to Linux. The description applies most closely to FreeBSD, which accounts for an estimated 80% of the BSD installations, but the differences from NetBSD, OpenBSD and DragonFlyBSD are small. 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 <trademark class="registered">UNIX</trademark>. 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.
Who owns BSD? Quem é o dono do BSD?
No one person or corporation owns BSD. It is created and distributed by a community of highly technical and committed contributors all over the world. Some of the components of BSD are Open Source projects in their own right and managed by different project maintainers. 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.
How is BSD developed and updated? Como o BSD é desenvolvido e atualizado?
The BSD kernels are developed and updated following the Open Source development model. Each project maintains a publicly accessible <emphasis>source tree</emphasis> which contains all source files for the project, including documentation and other incidental files. Users can obtain a complete copy of any version. Os kernels dos BSDs são desenvolvidos e atualizados seguindo o modelo de desenvolvimento Open Source. Cada projeto mantém uma <emphasis>árvore com código fonte</emphasis> 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.
A large number of developers worldwide contribute to improvements to BSD. They are divided into three kinds: Um grande número de desenvolvedores por todo o mundo contribuem com melhorias ao BSD. Eles estão divididos em três categorias:
<firstterm>Contributors</firstterm> write code or documentation. They are not permitted to commit (add code) directly to the source tree. In order for their code to be included in the system, it must be reviewed and checked in by a registered developer, known as a <emphasis>committer</emphasis>. <firstterm>Contributors</firstterm> 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 <emphasis>committer</emphasis>.
<firstterm>Committers</firstterm> are developers with write access to the source tree. In order to become a committer, an individual must show ability in the area in which they are active. <firstterm>Committers</firstterm> 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.
It is at the individual committer's discretion whether they should obtain authority before committing changes to the source tree. In general, an experienced committer may make changes which are obviously correct without obtaining consensus. For example, a documentation project committer may correct typographical or grammatical errors without review. On the other hand, developers making far-reaching or complicated changes are expected to submit their changes for review before committing them. In extreme cases, a core team member with a function such as Principal Architect may order that changes be removed from the tree, a process known as <firstterm>backing out</firstterm>. All committers receive mail describing each individual commit, so it is not possible to commit secretly. 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 <firstterm>backing out</firstterm>. 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 fonte em segredo.
The <firstterm>Core team</firstterm>. FreeBSD and NetBSD each have a core team which manages the project. The core teams developed in the course of the projects, and their role is not always well-defined. It is not necessary to be a developer in order to be a core team member, though it is normal. The rules for the core team vary from one project to the other, but in general they have more say in the direction of the project than non-core team members have. O <firstterm>Core Team</firstterm>. 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.
This arrangement differs from Linux in a number of ways: Esse arranjo difere do Linux de várias maneiras:
No one person controls the content of the system. In practice, this difference is overrated, since the Principal Architect can require that code be backed out, and even in the Linux project several people are permitted to make changes. 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.
On the other hand, there <emphasis>is</emphasis> a central repository, a single place where you can find the entire operating system sources, including all older versions. Por outro lado, <emphasis>existe</emphasis> 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.
BSD projects maintain the entire <quote>Operating System</quote>, not only the kernel. This distinction is only marginally useful: neither BSD nor Linux is useful without applications. The applications used under BSD are frequently the same as the applications used under Linux. Os projetos BSDs mantêm todo o <quote>Sistema Operacional</quote>, 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.
As a result of the formalized maintenance of a single SVN source tree, BSD development is clear, and it is possible to access any version of the system by release number or by date. SVN also allows incremental updates to the system: for example, the FreeBSD repository is updated about 100 times a day. Most of these changes are small. 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.
BSD releases Releases do BSD
FreeBSD, NetBSD and OpenBSD provide the system in three different <quote>releases</quote>. As with Linux, releases are assigned a number such as 1.4.1 or 3.5. In addition, the version number has a suffix indicating its purpose: O FreeBSD, o NetBSD e o OpenBSD fornecem o sistema em três diferentes <quote>releases</quote>. 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:
The development version of the system is called <firstterm>CURRENT</firstterm>. FreeBSD assigns a number to CURRENT, for example FreeBSD 5.0-CURRENT. NetBSD uses a slightly different naming scheme and appends a single-letter suffix which indicates changes in the internal interfaces, for example NetBSD 1.4.3G. OpenBSD does not assign a number (<quote>OpenBSD-current</quote>). All new development on the system goes into this branch. A versão de desenvolvimento do sistema é chamada de <firstterm>CURRENT</firstterm>. 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 (<quote>OpenBSD-current</quote>). Todo novo desenvolvimento no sistema entra neste branch.

Loading…

No matching activity found.

Browse all component changes

Glossary

English Portuguese (Brazil)
No related strings found in the glossary.

Source information

Source string comment
(itstool) path: sect2/para
Source string location
article.translate.xml:255
String age
a year ago
Source string age
a year ago
Translation file
articles/pt_BR/explaining-bsd.po, string 45