Copyright © 2003, 2004, 2005, 2006, 2007 Projeto de Documentação do FreeBSD
Este é o sítio Web do Projeto de Documentação do FreeBSD em Português Brasileiro, criado em 2003 pelo Grupo de Usuários Brasileiros de FreeBSD, FUG-BR. Todo documento disponível neste Web site está em constante desenvolvimento, exceto onde explicitamente denotado o contrário. Essa é a segunda fase do projeto, de volta ao trabalho após 18 meses de inatividade.
Versão Traduzida para Português do Brasil
Esta é uma tradução não-oficial do Aviso Legal Padrão do Projeto de Documentação do FreeBSD para o Português do Brasil. Ela não foi publicada pelo Projeto de Documentação do FreeBSD, e legalmente não representa os termos de distribuição de documentação que utiliza o Aviso Legal Padrão do Projeto de Documentação do FreeBSD -- somente o texto original do Aviso Legal Padrão do Projeto de Documentação, em inglês, faz isso. Logo, a versão traduzida não deve ser utilizada como um aviso legal válido. Esperamos, contudo, que esta tradução ajude aos falantes de Português do Brasil a entender melhor o Aviso Legal Padrão do Projeto de Documentação do FreeBSD.
SEMPRE verifique a versão em Inglês mais recente do Aviso Legal Padrão do Projeto de Documentação do FreeBSD na versão em Inglês do Manual do FreeBSD.
Redistribuição e utilização do código fonte (SGML DocBook) ou formato 'compilado' (SGML, HTML, PDF, PostScript, RTF e assim por diante) com ou sem modificação, são permitidas contanto que as seguintes condições sejam cumpridas:
As redistribuições do código fonte (SGML DocBook) devem reter o aviso de copyright acima, esta lista de condições e a seguinte nota de responsabilidade assim como as primeiras linhas deste arquivo não modificadas.
As redistribuições em forma compilada (transformada para outros DTDs, convertida para PDF, PostScript, RTF e outros formatos) devem reproduzir o aviso de copyright acima, esta lista de condições e a seguinte nota de responsabilidade na documentação e/ou outros materiais fornecidos com a distribuição.
Importante: ESTA DOCUMENTAÇÃO É FORNECIDA PELO PROJETO DE DOCUMENTAÇÃO DO FREEBSD "NO ESTADO" E QUAISQUER GARANTIAS EXPLÍCITAS OU IMPLÍCITAS, INCLUINDO, MAS NÃO LIMITADAS AS GARANTIAS IMPLÍCITAS DE COMERCIALIZAÇÃO E A DE ADEQUAÇÃO PARA UMA FINALIDADE PARTICULAR SÃO DESMENTIDAS. EM NENHUM EVENTO O PROJETO DE DOCUMENTAÇÃO DO FREEBSD PODERÁ SER RESPONSABILIZADO POR QUAISQUER DANOS DIRETOS, INDIRETOS, INCIDENTAIS, ESPECIAIS, EXEMPLARES, OU CONSEQÜENTES (INCLUINDO, MAS NÃO LIMITADO A, OBTENÇÃO DE BENS OU SERVIÇOS SUBSTITUTOS; PERDA DE USO, DE DADOS, OU DE LUCROS; OU A INTERRUPÇÃO DE NEGÓCIOS) DE QUALQUER FORMA CAUSADO E EM QUALQUER TEORIA DE RESPONSABILIDADE, SE EM CONTRATO, EM RESPONSABILIDADE ESTRITA, OU PROCESSUAL (PASSÍVEL DE PROCESSO, INCLUINDO NEGLIGÊNCIA OU NÃO) LEVANTADA DE QUALQUER FORMA PELO USO DESTA DOCUMENTAÇÃO, MESMO QUE AVISADO DA POSSIBILIDADE DE TAIS DANOS.
English Version
This is an unofficial translation of the Standard FreeBSD Documentation Project Legal Notice into Brazilian Portuguese. It was not published by The FreeBSD Documentation Project, and does not legally state the distribution terms for documentation that uses the Standard FreeBSD Documentation Project Legal Notice -- only the original English text of the Standard FreeBSD Documentation Project Legal Notice does that. Therefore, the translated version should not be used as a valid legal notice. However, we hope that this translation will help Brazilian Portuguese speakers understand the Standard FreeBSD Documentation Project Legal Notice better.
Make sure to ALWAYS check the latest English version of the Standard FreeBSD Documentation Project Legal Notice in the English documentation version of the FreeBSD Handbook.
Redistribution and use in source (SGML DocBook) and 'compiled' forms (SGML, HTML, PDF, PostScript, RTF and so forth) with or without modification, are permitted provided that the following conditions are met:
Redistributions of source code (SGML DocBook) must retain the above copyright notice, this list of conditions and the following disclaimer as the first lines of this file unmodified.
Redistributions in compiled form (transformed to other DTDs, converted to PDF, PostScript, RTF and other formats) must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution.
Importante: THIS DOCUMENTATION IS PROVIDED BY THE FREEBSD DOCUMENTATION PROJECT "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE FREEBSD DOCUMENTATION PROJECT BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS DOCUMENTATION, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
O projeto brasileiro de documentação do FreeBSD é formados por membros do Grupo Brasileiro de Usuários FreeBSD (FUG-BR) e tem por objetivo traduzir para a língua portuguesa os documentos produzidos pelo FreeBSD Documentation Project (FDP).
O trabalho de tradução é realizado diretamente nos originais em SGML, os quais são mantidos em um repositório CVS próprio até que estejam prontos (traduzidos e revisados) para serem incorporados à árvore CVS oficial Projeto FreeBSD.
O Projeto Brasileiro de Documentação do FreeBSD (FreeBSD Brazilian Portuguese Documentation Project), chamado comumente apenas de DOC-BR é composto de esforço voluntário de usuários do sistema, em geral membros da FUG-BR. Então por quê não juntar-se ao time?
Para fazer parte deste projeto você deve ter um apurado senso de responsabilidade e comprometimento, o que inclui especialmente não assumir mais atribuições do que você é capaz de cumprir, em especial em relação à tempo disponível para contribuir. Mas note bem, mesmo com pouca disponibilidade sua particiação é valiosa para o time.
É necessário boa capacidade de leitura de textos técnicos em língua inglesa, ou qualquer outra língua cujo Projeto de Documentação do FreeBSD esteja disponível e mantido em suas últimas revisões, como Francês, Alemão e Japonês. É necessário também fluência em língua portuguesa escrita e em especial familiaridade com termos técnicos. O time é relativamente grande, portanto facilidade para trabalho em equipe é essencial bem como a correta observância de regras, pois além de cumprir com os preceitos originais do FDP o DOC-BR ainda faz uso de regras e padrões próprios.
Se você se encaixa neste perfil, sua presença no time será valiosa. Para tal, o primeiro passo é ler atentamente o Primer do Projeto de Documentação do FreeBSD, disponível em Português Brasileiro aqui e em Inglês aqui.
Após a leitura do FDP se ainda assim você quiser se juntar ao time, siga para o Capítulo 2 deste documento.
O DOC-BR é constituído de membros que atuam em uma ou mais atividades dentro dos seguintes papéis:
Tradutor 1 (Inglês para Português Brasileiro)
É o mais comum tradutor, que desempenha o maior número de trabalho dentro do projeto. É responsável por traduzir a documentação original do Projeto FreeBSD da língua inglesa para o português falado no Brasil. Deve cumprir os requisitos anteriormente descritos.
Tradutor 2 (Português Brasileiro para Inglês)
É menos comum mas igualmente importante. Ao ler o FDP você soube que para incluir informações localizadas em algum documento já existente dentro do Projeto, o time de localização deve antes submete-las à documentação original, em inglês. Isso é para garantir integridade de conteúdo em qualquer língua. Complementarmente qualquer contribução completa (livro ou artigo) que desejemos criar oficialmente, tem antes que ser aprovado em língua inglesa. Aqui entra o Tradutor 2.
O Tradutor 2 deve ter grande facilidade para escrita formal e técnica em língua inglesa. Não precisa ser fluente pois a documentação submetida será revisada por nativos desta língua, contudo, não é possível o uso de linguagem coloquial. É através do Tradutor 2 que a comunidade conseguirá submeter contribuições à documentação oficial do Projeto FreeBSD.
Marcador / Revisor de Marcação SGML
Trata-se do contribuidor responsável por criar arquivos SGML que conformem com o padrão DocBook DTD expandido pelo FDP. Para desempenhar essa função o indivíduo deve ter facilidade e principalmente gostar de marcação XML-compatível, além de estudar detalhadamente as entidades e tipos de documentos criados exclusivamente pelo FDP. Em resumo, pessoa que conheça o Primer do Projeto de Documentação do FreeBSD em detalhes, bem como o processo de construção de documentos do FDP, disposição de Makefiles e detalhes de rotinas make(1) relacionadas ao Projeto de Documentação.
O Marcador SGML é responsável por revisar documentos SGML traduzidos por outros membros menos familiarizados com a linguagem, e por criar novos documentos inteiros para submissão junto à Documentação Oficial do Projeto. De maneira geral funções de Marcador SGML são frequentemente desempenhadas por Tradutores 1 e 2, ainda que de forma mais superficial. Mas em geral são também obrigações destes conhecer o essencial sobre esta atividade.
Marcadores SGML que gostem deste trabalho são espécies raras e em extinção. Se você é um deles, seu esforço será muito apreciado.
Revisor Lingüista
É o responsável por revisar gramática, ortografia e contexto dos documentos traduzidos, bem como garantir conformidade dos ítens traduzidos com o Glossário de expressões comuns usados pelo DOC-BR.
Pode desempenhar função de revisor para língua inglesa no caso de documentações inéditas, mas usualmente revisa a tradução do Inglês para Português Brasileiro. É uma função não raramente desempenhada por tradutores ao revisar textos de outros membros do time.
O primeiro e mais importante desafio do DOC-BR é traduzir toda a documentação oficial do Projeto FreeBSD, essencialmente sob as categorias Livros (books) e Artigos (articles). Este é o grande desafio, e o fóco primário de trabalho são os livros Handbook do FreeBSD e FAQ do FreeBSD.
FAQ -- Perguntas Frequentes Sobre o FreeBSD
Tratam-se das Perguntas Mais Frequentes sobre o FreeBSD, é originalmente o primeiro trabalho completo terminado pelo DOC-BR em um esforço centralizado desempenhado pela FreeBSD Brasil e revisado pela comunidade. Foi o ponta-pé inicial para o DOC-BR. Hoje o conteudo precisa ser atualizado. Está em conformidade com a revisão 1.456 do documento original em Inglês.
Artigo escrito por “Jordan K. Hubbard” aborda as diferentes maneiras como um indivíduo, organização ou grupo de usuários pode contribuir com o Projeto FreeBSD. Está em conformidade com a revisão 1.496 do documento original em Inglês.
FDP Primer -- Primer do Projeto de Documentação do FreeBSD para novos colaboradores
Este Primer do Projeto de Documentação do FreeBSD cobre tudo o que você precisa saber para começar a contribuir com o Projeto de Documentação do FreeBSD, desde as ferramentas e softwares que que você estará utilizando (tanto os obrigatórios quanto os recomendados) à filosofia por trás do projeto de documentação.
Está em conformidade com a revisão 1.20 do documento original em Inglês.
No mundo do código aberto, a palavra “Linux” é quase um sinônimo de “Sistema Operacional”, mas esse não é o único sistema operacional UNIX™ de código aberto. De acordo com o Contador de Sistemas Operacionais da Internet, em Abril de 1999 31.3% das máquinas conectadas na rede rodam Linux. 14.6% rodam BSD UNIX. Alguns dos responsáveis pelas maiores operações da rede no mundo, como o Yahoo!, rodam BSD. O servidor FTP mais requisitado do mundo, ftp.cdrom.com, usa BSD pra transferir 1.4 TB de dados por dia. É claro, que não se trata de um nicho de mercado: O BSD é um segredo muito bem guardado.
Então, qual é o segredo? Por que o BSD não é melhor difundido, mais conhecido? Esse documento abordará essas e outras questões.
Está em conformidade com a revisão 1.7 do documento original em Inglês.
Escrevendo relatórios de problema no FreeBSD
Este artigo descreve qual a melhor forma de formular e de submeter um relátorio de problemas para o Projeto FreeBSD.
Está em conformidade com a revisão 1.17 do documento original em Inglês.
Como obter o melhor resultado para as suas perguntas na lista de discussão FreeBSD-Question
Este documento prove informações úteis para as pessoas que planejam enviar um email para a lista de discussão FreeBSD-questions. Os avisos e conselhos foram elaborados com o com objetivo de maximizar as chances de que o leitor receba respostas úteis para as suas mensagens.
Este documento é enviado regularmente para a lista de discussão FreeBSD-questions. As dicas aqui mencionadas são também indicadas para a lista FUG-BR, e de forma geral para qualquer outra lista de discussão com grande tráfego de e-mails semanais.
Está em conformidade com a revisão 1.2 do documento original em Inglês.
Guia de Jumpstart para o FreeBSD
Este artigo detalha o método utilizado para permitir que se instale o FreeBSD em equipamentos que utilizem a tecnologia Intel PXE para dar boot no equipamento através da rede.
Está em conformidade com a revisão 1.22 do documento original em Inglês.
Este é um artigo que trata sobre como espelhar o FreeBSD, o mesmo esta em fase de elaboração pelos coordenadores do sites espelho.
Está em conformidade com a revisão 1.42 do documento original em Inglês.
FreeBSD e Dispositivos de Estado Sólido
Os sistemas Embedded possuem a vantagem de ter a sua estabilidade aumentada devido a ausência completa de partes móveis (Discos rigidos). Entretanto é necessário levar em conta que geralmente estes dispositivos possuem pouco espaço de disco disponível, além de terem na durabilidade da midia de armazenamento outro fator crítico. Este artigo aborda o uso de dispositivos de armazenamento em estado sólido na criação de sistemas embedded.
Está em conformidade com a revisão 1.11 do documento original em Inglês.
Um guia sobre como implementar um terminal diskless X
Retirado do artigo original:
|
Um guia sobre como implementar um terminal diskless X Com a ajuda de alguns amigos da lista FreeBSD-hackers, eu pude criar um terminal X diskless. A criação do terminal X necessitou incialmente da criação de um sistema diskless com utilitários minimos montados via NFS. Estes mesmos passos foram utilizados para criar 2 sistemas diskless distintos. O primeiro é o altair.example.com. Um terminal X diskless o qual eu executo no meu velho 386DX-40. Ele possui um HD de 340 Mb, mas eu não quiz mudá-lo. Assim, ele da boot a partir do antares.example.com através da rede Ethernet. O segundo sistema é um 486DX2-66. Eu o configurei um FreeBSD Diskless, o qual não utiliza o disco local. O servidor neste caso é uma SUN 670MP executando Sun OS 4.1.3. O mesmo procedimento de configuração foi necessário em ambos. |
||
| --Escrito em primeira pessoa por “Jerry Kendall” | ||
Está em conformidade com a revisão 1.15 do documento original em Inglês.
Guia dos Novos Adeptos ao FreeBSD 5.X
Guia de referência para usuários migrando da série 4.X para 5.X ou superior.
Está em conformidade com a revisão 1.15 do documento original em Inglês.
Dialup firewalling com FreeBSD
Este artigo documenta como configurar um firewall utilizando uma conexão discada com o FreeBSD e o IPFW, e especificamente como implementar um firewall de filtragem de pacotes em cima de um endereço IP atribuido dinâmicamente. Este documento não aborda a configuração da sua conexão PPP propriamente dita.
Está em conformidade com a revisão 1.32 do documento original em Inglês.
Utilizando o FreeBSD em Laptops
FreeBSD trabalha bem em muitos laptops, com algumas advertências. Algumas questões específicas para rodar o FreeBSD em laptops, relacionando diferentes requerimentos de hardwares de desktops, são discutidas neste documento.
Está em conformidade com a revisão 1.19 do documento original em Inglês.
É a principal e mais utilizada referência de documentação oficial do FreeBSD. Traz abordagem de nível básico à intermediário da instalação e administração geral do sistema. É um trabalho em constante atualização, e é parte de um esforço voluntário de dezenas de contribuidores. Trata-se de uma das maiores e mais completas referências centralizadas sobre um sistema de Código Aberto conhecidas. Deve ser cuidadosamente lido por novos usuários do FreeBSD e constantemente revistos por usuários mais experientes, pois está em constante melhoria.
Está em conformidade com a revisão 1.2 do documento original em Inglês.
Handbook dos Desenvolvedores de Ports
É a referência primária para todo indivíduo que deseje conhecer mais sobre a Coleção de Ports do FreeBSD, em especial que deseje contribuir ativamente, tornando-se um mantenedor de ports já existentes ou novos ports. Documenta todas as regras e padrões sob os quais um port deve ser criado, incluindo exemplos de arquivos Makefile, variáveis como MASTERDIR, BROKEN FORBIDDEN, DEPRECATED, e considerações especiais sobre o subsistema de gerenciamento de aplicações de terceiros.
Está em conformidade com a revisão 1.349 do documento original em Inglês.
Guia de compatibilidade de Hardware para FreeBSD Documenta todos os chipsets e equipamentos sabidamente suportados de forma plena pelo FreeBSD. Deve ser usado como referência antes de adquirir novo hardware voltado para o sistema.
Está em conformidade com a revisão 1.4 do documento original em Inglês.
Tradução do Web site do Projeto FreeBSD
O Web site do Projeto FreeBSD é um conjunto de documentos cuja manutenção demanda muita disponibilidade de muitos indivíduos, realidade por enquanto não compatível com a atual formação do time DOC-BR. O Web site é extremamente volátil, conta com dezenas de atualizações diárias, e por isso demanda atenção especial. É o ítem menos prioritário para o DOC-BR. Contudo se você deseja e tem disponibilidade para considerar manter o Web site do Projeto, entre em contato conosco.
Como o Web site do Projeto é intimamente conectado com os artigos e livros que constituem a documentação oficial do FreeBSD, o voluntário deve necessáriamente conhecer os procedimentos relacionados à manutenção destes documentos. Ou seja, já ter sido parte dos outros esforços do DOC-BR.
Tradução das páginas de manuais do FreeBSD
As páginas de manuais online do FreeBSD tem característica de ser extremamente ricas em detalhes e exemplos. São em geral mantidas pelos próprios desenvolvedores do sistema quando criam ou atualizam as aplicações ou recursos do kernel, bem como aplicações da userland, bibliotecas, e outros ítens relacionados ao sistema operacional. A revisão e melhoria dessas páginas de manuais, bem como devida formatação das mesmas é função do FDP. Contudo, quando esse trabalho é assumido por um Time de Localização como o Projeto de Documentação do FreeBSD em Português Brasileiro, este tem o trabalho de traduzir e manter atualizadas todas as páginas de manuais do sistema. Trata-se de um trabalho de dedicação prioritária pois, uma vez disponíveis, as páginas de manuais não podem jamais estar em conformidade com revisões passadas, que não as revisões mais recentes à cada ciclo de versões do FreeBSD. Ou seja a cada novo RELEASE, que ocorre em média de quatro em quatro meses, todas as páginas de manuais tem que ser revisadas e atualizadas. É um trabalho árduo e que demanda dedicação.
Outra característica desse trabalho, é que o voluntário deve conhecer outras ferramentas além das comuns ao FDP, como groff(1) e troff(1). Este é um trabalho não iniciado no DOC-BR. Tem menor prioridade e demanda maior comprometimento dos indivíduos envolvidos.
Agora que você já está por dentro do que é DOC-BR, conhece os documentos prontos e ainda sendo trabalhados por este projeto, já tem noção dos métodos de trabalho do time, pode decidir se deseja participar da equipe. Nesse capítulo você saberá um pouco sobre como e por onde começar.
Se você chegou aqui, é fundamental que já tenha lido o Primer do Projeto de Documentação do FreeBSD. Se não o fez ainda, acesse-o em Português Brasileiro aqui e em Inglês aqui.
O DOC-BR assume o método de trabalho indicado pelo Projeto de Documentação do FreeBSD, e possui ainda características próprias de trabalho. De forma geral todo trabalho é diretamente realizado por editores de texto que podem ser dos mais simples, como vi(1) e ee(1), à editores mais completos com vim(8) e emacs(8). O FDP aconselha uso do emacs(8) em especial por ele ter suporte à modo de operação SGML -- o chamado SGML-mode. No DOC-BR temos ainda que considerar a necessidade de trabalhar com acentos em padrão de entidades XML (SGML), isso quer dizer que palavras acentuadas não podem ter os acentos literais, mas sim, deve fazer uso dessas entidades para representar os caracteres especiais típicos de nossa língua -- chamados de padrão ISO 8859-1 ou suporte à caracteres latinos.
Por exemplo, a seguinte expressão:
Será escrito da seguinte forma:
Exemplo 2-2. Exemplo de acentos com entidades SGML
Este é o Projeto de Documentação do FreeBSD.
Portanto temos que decidir como trabalhar essa necessidade. Alguns (poucos é verdade) membros do projeto trabalham em editores simples como ee(1) e vi(1) e escrevem as frases diretamente com essas entidades. Contudo isso é incomum e quase não-humano (rs). Não temos esperança nem é nosso desejo que você goste de escrever e ler dessa maneira.
Por isso você pode usar outros métodos. Editores como vim(8) por exemplo tem o modo de tradução de caracteres. Quando abre um arquivo ele pode converter as entidades SGML para acentos em nosso padrão de caracteres, e ao fechar o arquivo ele converte de volta nossos caracteres para entidades SGML. Dessa forma ao ler/editar no vim(8) o indivíduo sempre terá o texto literal, e o resultado final salvo no arquivo serão as entidades. Tudo de forma transparente.
Outros membros preferem usar editores da base como vi(1) ou ee(1) e traduzir tudo com acentos. Antes de normalizar ou analisar a sintaxe do arquivo SGML contudo, transforma seus acentos em entidades SGML. Esse particularmente é o método que este que está escrevendo esse arquivo SGML adota.
Ou com emacs(8) você pode escolher como quer trabalhar. O fato é, você deve optar pelo editor de texto o qual tem mais aptidão e fica mais confortável para trabalhar. O trabalho é grande e não muito simples, então o editor de texto não precisa ser algo a mais à aprender ou adaptar-se.
O Projeto de Documentação em Português Brasileiro do FreeBSD dispõe de scripts e arquivos de configurações para auxiliar o trabalho do desenvolvedor. Portanto seja qual for sua opção editor de texto, terá ferramentas para auxiliá-lo. Complementarmente o time criou também um script em linguagem Perl que analisa o arquivo SGML e revisa algumas das principais regras do FDP. Por exemplo, você viu ao ler o Primer do Projeto de Documentação do FreeBSD que a identação das colunas deve seguir 2 caracteres de espaço. Que cada oito espaços devem ser substituídos por um \t (tab). Que o final de uma sentença deve ser denotado com dois espaços se não houver quebra de linhas ou final de parágrafo, que as linhas devem acabar no máximo na coluna 84 ou preferencialmente antes da coluna 70, etc. O script corrige todas as regras que ele for capaz e dispara um alerta para as regras que não conseguir corrigir.
A outra ferramenta que o contribuidor do DOC-BR deve conhecer, ao menos o básico é o cvs(1). Nosso projeto faz uso de um servidor cvs(1) para armazenas e possibilitar o trabalho paralelo das dezenas de membros simultâneamente. As vantagens do CVS é ter um controle rígido sobre versões, podendo restaurar um arquivo errôneamente modificado à qualquer momento, e possibilitar trabalho concorrente de diversos indivíduos. A desvantagem é que é algo mais à se aprender, caso você não tenha familiaridade com essa conhecida ferramenta.
Por último, o método de comunicação entre todos os membros do DOC-BR é através de correio eletrônico, especificamente a lista de discussão DOC disponível na $fug;. Saiba como participar da lista na seção seguinte deste documento.
Os participantes do Projeto DOC-BR fazem uso dessa lista de discussão para interagir, discutir e decidir cada etapa de trabalho do esforço de tradução para Português Brasileiro da documentação oficial do FreeBSD.
Outras converas sobre metodologia e decisões práticas de traduções, interpretações de texto, grafia, gramática e conformidade/atualização do glossário de expressões comuns às traduções também se passam nesta lista.
A lista chama-se apenas doc, e é hospedada diretamente na infra-estrutura da FUG-BR. Se você tem dúvidas, críticas ou sugestões acera do Projeto DOC-BR, e principalmente se quer se tornar parte desse esforço, cadastre-se na lista. Ela pode ser acessada aqui.
Complementarmente, o time utiliza uma lista auxiliar, denominada cvs. Esta lista tem o propósito de receber os logs de commit em qualquer projeto desenvolvido pela comunidade FUG-BR. Na prática, DOC-BR é o projeto que gera tráfego nesta lista hoje, já que os outros projetos FUG-BR (como FreeBSD LiveCD) foram concluídos. Contudo futuros projetos podem vir à acrecentar tráfego extra nesta lista. O fato é que essa é a forma mais simples e dinâmica para o contribuidor DOC-BR ficar à par de todas as modificações e atualizações que cada membro do Projeto tem feito.
Para se cadastrar nesta lista, acesse sua interface Web aqui.
DOC-BR adota o cvs(1) de “Brian Berliner” como sistema de versão concorrente para seu repositório fonte. É a versão do CVS disponível na base do FreeBSD e também na maioria dos outros sistemas de código aberto que adotam CVS.
Originalmente o DOC-BR criou seu ambiente de trabalho CVS hospedado no BerlioOS.de, site de formento à desenvolvimento de software de código aberto, similar ao Source Forge. Há recursos estruturais e técnicos para utilizar um servidor CVS próprio, contudo por enquanto não há qualquer justificativa prática para o trabalho de migração do BerlioOS para um servidor próprio do FUG-BR. Então hoje nosso CVS ainda fica no BerlioOS.
Portanto para tornar-se membro ativo do grupo, você deve criar sua conta no BerliOS, em http://developer.berlios.de/account/register.php.
Depois envie um e-mail para a lista de discussão da DOC-BR dizendo qual o seu nome de usuário no BerliOS, ou envie um e-mail em particular para “Patrick Tracanelli”, “Edson Brandi” ou “Mário Fujikawa”, que são os três coordenadores do projeto. Você será associado ao DOC-BR no BerliOS. Mas note que essa liberação pode levar até 24 horas após seu nome de usuário ser associado ao projeto (em média acontece de 6 em 6 horas).
Se você não pretende contribuir de forma ativa e tem apenas curiosidade sobre o andamento do projeto, pode consultar o servidor CVS sem ter usuário e senha. Para isso acesse-o como anônimo. Os procedimentos são:
% touch ~/.cvspass % cvs -d:pserver:anonymous@cvs.doc-br.berlios.de:/cvsroot/doc-br login
Será pedida senha de login. Dê um enter com a senha em branco (não digite nada).
Logging in to :pserver:anonymous@cvs.doc-br.berlios.de:2401/cvsroot/doc-br CVS password:
A partir desse momento você estará logado. Para obter os arquivos do projeto faça checkout de cada um dos módulos que constituem a árvore CVS do DOC-BR.
% cvs -d:pserver:anonymous@cvs.doc-br.berlios.de:/cvsroot/doc-br checkout nome do módulo
Por exemplo:
Exemplo 2-3. Fazendo checkout de um módulo CVS na DOC-BR
% cvs -d:pserver:anonymous@cvs.doc-br.berlios.de:/cvsroot/doc-br checkout pt_BR.ISO8859-1
Para saber quais os módulos disponívels leia a próxima seção.
O repositório CVS do Projeto de Documentação do FreeBSD em Português Brasileiro no BerliOS dispõe dos seguintes módulos (diretórios):
doc-br/
Utilizado apenas pelo próprio servidor CVS e pelo administrador do CVS, não é algo com que os membros do projeto devam se preocupar.
pt_BR.ISO8859-1/
Trata-se da estrutura ISO de todos os livros e artigos trabalhados pelo FDP, na língua Português Brasileiro. É a estrutura importada junto ao CVS oficial do FreeBSD sempre que cada novo artigo ou livro está pronto. A constituição desse documento é rígidamente disposta no padrão que você leu no Primer do Projeto de Documentação do FreeBSD e que portanto já conhece. Como não é particular à DOC-BR não será documentado aqui. É essencial que você tenha lido o Primer do Projeto de Documentação do FreeBSD.
Essa estrutura no sistema é o /usr/doc/pt_BR.ISO8859-1/ quando o usuário sincronizou a documentação do sistema através de CSup por exemplo. O resultado construído dessa estrutura (documentos criados/compilados) são instalados sob /usr/share/doc/pt_BR.ISO8859-1/ em um sistema FreeBSD com documentação instalada (por CD-ROM por exemplo). Note que /usr/doc/pt_BR.ISO8859-1/ é distinto de /usr/share/doc/pt_BR.ISO8859-1. O primeiro só está disponível se o usuário obter via sincronia com repositório FreeBSD, e trata-se dos SGML, entidades e DTDs (ou seja, o código fonte da documentação), enquanto o segundo é o resultado pronto (já compilado) em formato HTML, texto plano, PDF, PostScript e outros, que pode ser instalado do CD-ROM por exemplo.
tools/
Neste módulo ficam os scripts e arquivos criados e utilizados pelo DOC-BR. Ele é constituído dos subdiretórios babylon/, scripts/, vim/ e sandbox/. Tem ainda os arquivos Readme.txt e palavras.txt. O diretório babylon/ é usado por pessoas que trabalham com emacs(8). Ele contém instruções e base de dados para tradução de textos simples de português para inglês. As traduções devem ser usadas apenas como referência e jamais ser usadas integralmente no contexto do documento traduzido. O diretório tem um arquivo Readme.txt com todas as intruções sobre como configurar e utilizar esse recurso no emacs(8).
O diretório scripts/ tem os scripts criados e mantidos pela DOC-BR para colocar os documentos em conformidade com as regras do FDP. Ao menos um script deve ser sempre utilizado por todos membros do DOC-BR, trata-se do fdp.pl, escript por “Diego Linke”. Ele recebe como entrada o arquivo SGML e na saída gera o mesmo arquivo (stdout) com as regras do projeto corrigidas, e com alertas que o tradutor deve estar atento.
Outro arquivo muito útil do diretório tools/ é o acentos.sed. Ele serve como arquivo de parâmetro para o sed(1), e faz a conversão de acentos em nosso conjunto de caracteres para acentos com entidades SGML. Uso obrigatório para desenvolvedores que não trabalham com editores que fazem essa conversão automáticamente como vim(8) ou emacs(8).
No diretório vim/ você encontrará o mesmo conteúdo do /usr/doc/share/examples/vim em seu sistema após sincronizar a documentação. São os arquivos e scripts usados para configurar a conversão automática de acentos no vim(8).
O diretório sandbox/ dentro do módulo tools/ é uma área livre para experiências CVS de novos usuários. Todos podem editar e adicionar novos arquivos dentro deste diretório, para ficarem mais à vontade com o CVS. Dentro dele você encontrará o diretório exercicios/ com vários arquivos SGML com exercícios propostos pelo FDP bem como algumas variações destes.
Finalmente os arquivos palavras.txt são palavras as quais os revisores devem se atentar, pois usualmente os tradutores esquecem de acentuar. O Readme.txt é o arquivo de informações mais completo disponível pelo DOC-BR no CVS. Parte do conteúdo deste você encontrará aqui também. É leitura obrigatório se além de contribuir com o DOC-BR você pensa também em se aprofundar nos detalhes sobre como a documentação do FreeBSD funciona, detalhes sobre arquivos Makefile por exemplo, bem a construção/compilação dos documentos para outros formatos (PDF, doc, etc), ou se você também pretende trabalhar com emacs(8).
glossario/
Trata-se do glossário de palavras e expressões comuns em inglês, que encontraremos frequentemente durante o trabalho de tradução. Como o projeto é constituído de diversos indivíduos, o glossário também serve como padronização lingüísta, para garantir que textos distintos traduzidos por pessoas diferentes sejam traduzidos da mesma forma quando essas expressões especiais aparecerem, não sendo notadas diferenças para o leitor.
Dentro desse diretório além do próprio glossario.txt há também um arquivo LEIAME.glossario.txt. Este serviu de inspiração para os próximos parágrafos.
Todo tradutor deve sempre seguir à risca as expressões adotadas no glossário. Quando você se deparar com uma expressão especial que não tem certeza sobre como traduzi-la, e esta não estiver no glossário ainda, saiba que você está diante de um candidato em potencial para nova entrada no glossário. Portanto envie para a lista de discussão DOC-BR suas dúvidas sobre essa expressão para que todos membros possam discutir sobre como ela deve ser colocada no glossário.
Algumas traduções são estranhas mas devemos tentar seguir a norma oficial do português brasileiro. Afinal de contas, quem ler a versão em português provavelmente estará acostumado com estes termos traduzidos. Quem acha muito estranho (prefere eles em inglês) provavelmente lerá a versão em inglês de qualquer maneira.
Por exemplo, a traduçãoo escolhida pelos especialistas em teoria da informação para “site” é s&ítio. Muitos consideram de péssimo gosto, mas é o correto, então vamos nos esforçar para usá-la. Em casos especiais podemos usar <literal>Web site</literal>.
Já em casos mais cabulosos, ninguém vai concordar com os especialistas e traduzir palavras consagradas como “kernel”, para cerne ou núcleo. Apesar de correta, a tradução estraga o prazer da leitura. Nesse caso, opte por usar a expressão original de forma literal, <literal>kernel</literal>.
A regra para uso do glossário é simples. Do lado esquerdo temos a expressão original, e do lado direito as possibilidades de traduções. Opte pela que melhor se encaixar no contexto. Do lado direito essas possibilidades são denotadas com | que significa “ou”. Portanto A|B é A ou B. Prefira as primeiras entradas. Por exemplo:
Prefira “reinvidicada” sempre que possível ou em caso de dúvida. Se no contexto as outras opções ficarem melhor, use-as então.
src/
São os documentos de distribuição, íntriseco e diretamente relacionado ao lançamento de novas versões do FreeBSD. No sistema, é o conteúdo disposto em /usr/src/release/doc/. Nele estão por exemplo as Notas de Hardware.
www/
Trata-se do sítio Web do Projeto FreeBSD. Nenhum documento primário está atualmente sendo trabalhado sob este módulo.
Aqui você acompanhará o essencial sobre o que é preciso saber de cvs(1) para desempenhar corretamente as funções na DOC-BR quando você já for membro do time.
Nota: Para acessar o servidor CVS do DOC-BR com privilégios para atualização e adição de novos documentos é necessário um nome de usuário válido no BerlioOS. Você soube anteriormente como criá-lo. Quando a associação ao projeto DOC-BR concluir, será possível acessar o CVS com privilégios de escrita.
Para criar seu ambiente de trabalho, aconselhamos fortemente que as principais configurações e informações comuns ao seu ambiente CVS sejam definidas em variáveis de ambiente, ao invés de passá-las frequentemente por parâmetro em linha de comando, como mencionado anteriormente para acesso anônimo.
As variáveis de ambiente e seus respectivos valores em um intepretador de comando compatível com a Bourne Shell (sh(1)) devem ser criadas da seguinte maneira:
Exemplo 2-5. Variáveis de ambiente para cvs(1) em Bourne Shell
CVS_RSH=ssh export CVS_RSH CVSROOT=:ext:seulogin@cvs.doc-br.berlios.de:/cvsroot/doc-br export CVSROOT
Para tornar essa modificação permanente adicione estas linhas no seu ~/.profile ou no profile do sistema. Substituia seulogin por seu nome de usuário.
No caso do interpretador de comandos ser compatível C Shell (como csh(1) ou tcsh(1), padrão em sistemas BSD) defina as variáveis:
setenv CVS_RSH ssh setenv CVSROOT :ext:seulogin@cvs.doc-br.berlios.de:/cvsroot/doc-br
Para tornar estas mudanças permanentes, coloque-as no ~/.cshrc ou em /etc/csh.cshrc. Substitua seuloginpor seu nome de usuário.
Agora já é possível acessar o repositório CVS. Mas é necessário decidir e customizar seu ambiente de trabalho. Para isso seguem algumas sugestões adotadas no DOC-BR. Você pode modificá-las como achar mais conveniente caso esteja completamente seguro em trabalhar com CVS.
Dentro de seu diretório home (~/) crie um diretório chamado CVS_ROOT. Nele você assumirá raiz de todo seu trabalho em sistemas CVS, mesmo que existam outros além do DOC-BR. Dentro dele crie o subdiretório doc-br. Este sim exclusivo à nossas atividades.
Entre neste diretório:
% cd ~/CVS_ROOT/doc-br/
e nele dê o comando
% cvs checkout pt_BR.ISO8859-1
Antes de iniciar qualquer trabalho em um determinado módulo, sempre execute o comando cvs update dentro deste módulo:
% cd pt_BR.ISO8859-1/ % cvs update
Dessa maneira qualquer modificação que um outro membro do time tiver feito nesses arquivos serão atualizadas na sua máquina local, e você mantem completa integridade entre o seu módulo e o módulo remoto, sem a necessidade de obter os arquivos todos novamente com cvs checkout.
Sempre execute os comandos cvs commit dentro do diretório do capítulo que estiver traduzindo, de forma à diminuir o risco de sobrescrever cópias desatualizadas em documentos modificados por outros membros do time. Mesmo sabendo que trabalhar com CVS é um processo seguro, já que ele alerta sobre este conflito e permite ao usuário corrigi-lo, ainda assim é um procedimento bom à se acostumar.
Sempre que você parar de traduzir um arquivo, mesmo que seja temporário, digamos para tomar um lanche ou ver TV, faça o commit. Com o cvs commit você deixará seus colegas de time por dentro do que já fez, e garantirá snapshots atualizados do estado atual da documentação, além claro de não correr riscos de perder seu trabalho caso aconteça alguma tragédia no seu computador neste meio tempo.
Se desejar ler todo o histórico de logs de commits em um dado arquivo, use o comando:
% cvs log arquivo
Se desejar ver o que mudou de uma revisão para outra, em um dado arquivo, é possível executar um diff(1) remoto no cvs(1). Para isso dê:
% cvs diff -rrevisão_atual -rrevisão_anterior_desejada nome_do_arquivo
Caso queira saber mais sobre CVS ou ainda restem dúvidas, não deixe de ler o documento sobre CVS disponível em http://cvsbook.red-bean.com/. Mas de maneira geral você não precisará conhecer mais operações no CVS do que as mencionadas aqui.
Evite ao máximo enviar em um mesmo commit alterações de conteúdo e de formatação SGML. Isso porquê cada novo commit gera uma nova revisão do arquivo, e caso seja necessário restaurar o arquivo como era antes da formatação ou antes da alteração de conteúdo, não será possível já que ambas mudanças foram feitas no mesmo commit. Quanto mais commit melhor!
Trataremos aqui apenas das ferramentas criadas e utilizadas constantemente pelo DOC-BR. Tratam-se dos arquivos disponíveis sob o módulo tools/ no repositório CVS. Já vimos o que são e o que fazem esses arquivos, agora vamos aprender a usá-los.
O fdp.pl como já mencionado, pega o arquivo SGML na saída padrão e retorna o mesmo conteúdo, porém tratado/modificado na saída. Portanto, como o resultado vai para saída padrão (stdout) ele deve ser redirecionado a um outro arquivo temporário. Use-o da seguinte forma:
% cp arquivo.sgml arquivo.sgml.bk % /caminho/para/fdp.pl arquivo.sgml > arquivo.sgml.novo
Analise o conteúdo na tela (mensagens de alerta) e o novo arquivo gerado, arquivo.sgml.novo. Estando ok, renomei-o para o arquivo original:
% mv arquivo.sgml.novo arquivo.sgml
Não se esqueça de fazer backup do arquivo antes (comando cp(1)).
Acompanhe exemplo prático de uso dessa ferramenta:
Exemplo 2-6. Exemplo de uso do fdp.pl
% cp book.sgml book.sgml.bkp % ~/CVS_ROOT/DOC-BR/tools/scripts/fdp.pl book.sgml > book.sgml.novo [..] ATENCAO: A linha 598 tem mais de 70 colunas tem 72 colunas ATENCAO: A linha 599 tem mais de 70 colunas tem 73 colunas ATENCAO: A linha 600 tem mais de 70 colunas tem 74 colunas ATENCAO: A linha 603 tem mais de 70 colunas tem 81 colunas ATENCAO: A linha 622 tem mais de 70 colunas tem 79 colunas Total de 9 linha(s) alterada(s) no arquivo book.sgml % % mv book.sgml.novo book.sgml
acentos.sed é usado como arquivo de parâmetros para o sed(1) (usado com a opção -f). Seu uso é similar ao fdp.pl pois o sed(1) também receberá o arquivo original como entrada e gerará o resultado na saída padrão. Portanto para usá-lo faça como no exemplo:
XXX pendente. Preciso levantar essas informações com quem usa o vim(8).
Os outros arquivos, grep.sh, man.sh, unman.sh e space2tab.sh são rotinas para verificar e corrigir os ítens das regras do FDP, mas separados, para análises independentes. Normalmente são usados apenas por revisores mais minuciosos, já que as funções desempenhadas por estes são todas desempenhadas também pelo fdp.pl. Portanto dê preferência por usar o fdp.pl.
Como parte de um exercício muito simples, faça checkout de todos os módulos relevantes do CVS do Projeto DOC-BR. Depois entre no diretório tools/sandbox/exercicios:
% cd ~/CVS_ROOT/doc-br % cvs co tools % cvs co pt_BR.ISO8859-1 % cvs co glossario % cd ~/CVS_ROOT/doc-br/tools/sandbox/exercicios
Neste diretório, observe uma série de arquivos SGML. Você pode utiliza-los da forma como achar conveniente, fique a vontade para modificá-los todos. Mas a primeira atividade proposta é com o arquivo exercicio-novo-membro.sgml.
Edite-o e modifique as entidades versao e author. Incremente “versao” em 0.1 (por exemplo, se ela é 1.2, coloque como 1.3) e modifique seu nome em author.
Com nsgmls verifique a integridade desse arquivo SGML:
% nsgmls -s exercicio-novo-membro.sgml
Se houver erro, corrija-os. Em seguida faça a normalização desse arquivo SGML para HTML com a aplicação sgmlnorm mantendo o DOCTYPE no resultado normalizado.
% sgmlnorm -d exercicio-novo-membro.sgml > exercicio-novo-membro.html
Analise então o conteúdo do arquivo e veja se as frases que mencionam a versão e autor do arquivo estão apresentando essa informação de maneira correta.
AtençãoNenhum desses dois passos são relacionados ao trabalho diário do DOC-BR, mas são etapas que o membro deve em teoria ter uma noção mínima de como funcionam, pois é isso que acontece quando compilamos nossos SGML tornando-os arquivos em formatos finais (PDF, doc, HTML, etc). Se no seu sistema não tem essas aplicações, então você não instalou o meta-port textproc/docproj, sendo assim provavelmente não leu o Primer do Projeto de Documentação do FreeBSD atenciosamente. Nesse caso você não precisa continuar lendo esse texto, pois estará desperdiçando seu tempo, e potencialmente o nosso. Usuários sem a sensibilidade para entender a relevância do Primer do Projeto de Documentação do FreeBSD e dos exercícios nele propostos não estão áptos à prover ajuda apreciada pela DOC-BR -- a não ser em casos muito especiais (já ter participado de um projeto desse tipo ou ter familiaridade com DocBook, por exemplo). Se não é o seu caso desconsidere esse parágrafo. Se é, por gentileza leia o Primer do Projeto de Documentação do FreeBSD atentamente.
Agora sim, finalmente vamos exercitar tarefas diárias do projeto. Ao acabar de editar o SGML, use o fdp.pl para verificar se houveram correções no arquivo:
% cp exercicio-novo-membro.sgml exercicio-novo-membro.sgml.bkp % ~/CVS_ROOT/DOC-BR/tools/scripts/fdp.pl exercicio-novo-membro.sgml > exercicio-novo-membro.sgml.novo Total de 2 linha(s) alterada(s) no arquivo exercicio-novo-membro.sgml
Caso hajam correções você verá uma linha de sumário similar à esta, dizendo o número de linhas alteradas. Não é possível saber quais alterações foram feitas e em quais linhas através do próprio fdpl.pl. De qualquer maneira no dia-a-dia não será necessário analisar o que foi modificado pela ferramenta, mas se desejar fazê-lo em alguma sitação particular, pode usar o diff(1), por exemplo:
Exemplo 2-8. Exemplo de uso do diff(1) para verificar modificações locais
% diff -u exercicio-novo-membro.sgml exercicio-novo-membro.sgml.novo
Ao terminar a correção com fdp.pl, renomeie o novo arquivo para o arquivo original:
% mv exercicio-novo-membro.sgml.novo exercicio-novo-membro.sgml
Agora é a vez de usar o sed(1) para transformar acentos em entidades SGML:
% sed -f ~/CVS_ROOT/DOC-BR/tools/scripts/acentos.sed exercicio-novo-membro.sgml > exercicio-novo-membro.sgml.novo % mv exercicio-novo-membro.sgml.novo exercicio-novo-membro.sgml
Em ambos os casos, nesse primeiro exercício você pode usar fdp.pl e o sed(1) sem apontar o novo arquivo, e analisar apenas a saída padrão. Nesse caso a alteração não terá sido feita, mas como o arquivo de exercício é pequeno você terá uma visão clara das modificações, em especial no caso do sed(1) com acentos.sed. No dia-a-dia esta prática não é muito viável pois o arquivo sendo trabalhado será grande.
Agora é hora de finalmente efetivar sua modificação, com um commit:
% cvs commit exercicio-novo-membro.sgml Password:
Ao término do commit você terá enviado seu arquivo para o CVS, portanto agora a versão disponível remotamente é a mesma que você tem localmente. Você notará que ao enviar o commit, o cvs(1) abrirá uma tela no seu editor de texto padrão (conteúdo da variável de ambiente EDITOR). Nele você deve escrever o log do motivo de seu commit. Você pode evitar este editor de textos e enviar a mensagem de log já na linha de comando, para tal use a opção -m do cvs(1):
% cvs commit -m 'atualizacao para versao 1.2, modificacao do author para meu nome' exercicio-novo-membro.sgml
Não faça commit sem logs!. Os logs não precisam ser detalhados, mas ao menos mencione o que foi feito. Por exemplo, logs ruins seriam:
Exemplo 2-9. Exemplos de maus logs de commit
“corrigindo ultimo problema”
“atualizando”
“continuando traducao, mais um pouco”
Nesses casos os logs mínimos deveriam conter:
Exemplo 2-10. Exemplos bons e curtos de logs de commit
“corrigindo problema por falta de entidade e erro de digitacao”
“atualizando capitulo 3, adicao de novo paragrafo, conformidade com rev 1.445”
“continuando traducao, agora 45% esta pronto; traduzido ate capitulo 4”
Dessa forma apenas lendo a mensagem de log do commit os companheiros de equipe saberão exatamente o que está acontecendo.
Para exercitar, tire diffs remotos desse arquivo com cvs diff, e se desejar modifique outros arquivos desse diretório e faça commit deles. Consulte também os logs dos arquivos com "cvs log".
Você notou que o método de autenticação CVS usado no DOC-BR é o SSH. Notou também que no commit o servidor CVS solicitou senha. De fato não só para cada commit, mas para cada ação como update ou checkout o servidor CVS sempre solicitará senha. Isso garante que o usuário que está fazendo o acesso CVS é mesmo quem ele diz ser.
Contudo alguns membros do time consideram ter que enviar a senha a todo momento incômodo demais. A solução nesse caso é configurar o ssh(1) para trabalhar com autenticação por chave pública ao fazer qualquer acesso no servidor CVS do Projeto DOC-BR.
Se você já tem uma chave privada, copie o par público dela (a chave pública) para o arquivo ~/.ssh/authorized_keys no servidor shell.berlios.de.
Se ainda não tem, é um bom momento para criá-la. Crie sua chave com o ssh-keygen(1). No caso do BerliOS especificamente a chave deve ser do tipo rsa. Use o parâmetro -t rsa do ssh-keygen(1). Note que a aplicação solicitará algumas informações, em especial onde armazenar suas chaves públicas e privadas (que em geral tem o nome id_rsa e id_rsa.pub no caso de chaves rsa. Solicitará também uma passphrase, que será a contra-chave para sua chave privada. Acompanhe o exemplo:
Exemplo 2-11. Exemplo de criação de chave pública e privada
% ssh-keygen -t rsa Generating public/private rsa key pair. Enter file in which to save the key (/usr/home/usuario/.ssh/id_rsa): Created directory '/usr/home/usuario/.ssh'. Enter passphrase (empty for no passphrase): Enter same passphrase again: Your identification has been saved in /usr/home/usuario/.ssh/id_rsa. Your public key has been saved in /usr/home/usuario/.ssh/id_rsa.pub. The key fingerprint is: c1:b4:83:97:bb:6e:a7:08:58:76:e5:b1:ba:3e:1a:40 usuario@seu.hostname.domainname
Em seguida copie sua chave pública para o servidor BerliOS:
% cat ~/.ssh/id_rsa.pub | ssh usuario_no_berlios@shell.berlios.de "cat - >>.ssh/authorized_keys"
Agora sempre que necessário, inicie o ssh-agent(1) apenas uma vez durante sua sessão de trabalho. Ele cuidará de enviar seu passphrase sempre que necessário, quando já estiver configurado. Para saber mais sobre o ssh-agent(1) e como configurá-lo, consulte a documentação do OpenSSH em http://openssh.org/.
Se desejar você pode ainda criar uma chave privada sem passphrase. Enquanto isso diminuirá drásticamente a segurança em potencial do ambiente, aumentará também a simplicidade. Se o passphrase não for usado, a autenticação remota se dará apenas com a chave privada, não sendo necessário jamais entrar a passphrase e como consequência, não sendo necessário o uso do ssh-agent(1).
Para gerar uma chave privada sem passphrase basta repetir o procedimento citado acima, mas quando o ssh-keygen(1) solicitar a passphrase dê apenas um ENTER. Quando solicitar confirmação do passphrase dê apenas um ENTER novamente.
AtençãoNote que se você criar uma chave privada sem passphrase, a autenticação acontecerá apenas com o uso de sua chave privada. Portanto multiplique seus cuidados com o arquivo ~/.ssh/id_rsa mil vezes. Qualquer pessoa que puder obter uma cópia desse arquivo poderá acessar o servidor com a chave pública correspondente à esta chave privada. No caso da DOC-BR, se alguém copiar o seu ~/.ssh/id_rsa poderá acessar o repositório CVS com seu usuário, mesmo não sabendo sua senha.
Salvo esta consideração, se você cuidar bem de sua chave privada pode criá-la sem passphrase para uso no CVS.
Agora ao acessar o servidor CVS do Projeto DOC-BR basta antes iniciar o ssh-agent(1). Ou se a chave privada não tem passphrase, nem isso é necessário, a autenticação das suas ações se fará por meio de chave privada, não sendo mais necessário entrar a senha de seu usuário cada vez que fizer acesso ao servidor cvs(1).
Lembre-se, sistemas, programas e arquivos não são pessoas então em geral não possuem gênero. Portanto evite artigos antes dessas expressões sempre que possível, em especial antes da palavra FreeBSD.
Por exemplo:
Exemplo 2-12. Exemplo 1 de expressões com artigo e gênero
Bem vindo às Perguntas mais freqüentes da série 2.X até a 4.X para o FreeBSD!
Poderia ser:
Exemplo 2-13. Exemplo 2 de expressões com artigo e gênero
Bem vindo às Perguntas mais freqüentes da série 2.X até 4.X para FreeBSD!
Nesse caso evitamos o artigo quanto à versão do sistema operacional e o gênero do FreeBSD. Poderia ser ainda mais simples (em geral, quanto mais simples melhor):
Exemplo 2-14. Exemplo 3 de expressões com artigo e gênero
Bem vindo às Perguntas mais freqüentes para as versões 2.X á 4.X do FreeBSD!
Nesse caso evitamos todos artigos e gêneros possíveis antes das expressões mencionadas, tornando o texto mais simples e claro de ser lido. Mantivemos o que é essencial para o contexto. As três frases dizem exatamente a mesma coisa.
Depois de separador frasal, use dois espaços e não apenas um. Isso ajuda quem utiliza o emacs(8) e também facilita a percepção de término de frase para o compilador/interpretador que fará as normalizações e conversões SGML. Isso se deve ao fato de que nem sempre separadores frasais mais comuns, como ponto e vírgula (;) e ponto final (.) aparecem no término de frases. Por exemplo:
Exemplo 2-15. Exemplo de separador frasal fora de término de sentença
O criador do UFS é Marshall K. McKusick. McKusick projetou também o UFS2 no FreeBSD e participou ativamente da reimplementação deste sistema de arquivos em sua segunda encarnação.
Está claro que o separador frasal ponto (.) nesse caso tem funções completamente distintas em “Marshall K.” de “McKusick.” ou “encarnação.”. Contudo para uma máquina essa distinção não existe.
Acrônimos também não tem gênero. Por exemplo, não há porque ter dúvidas entre "a FAQ" ou "o FAQ"; FAQ não é menino nem menina, portanto é apenas FAQ.
Expressões que não podem ser traduzidas mas não são técnicas devem ser identificadas como expressão em língua extrangeira, para tal ela deve ficar entre <foreignphrase></foreignphrase>. Caso a expressão seja um termo consagrado em qualquer língua como como kernel, FAQ, SPAM ou home, estas devem ser consideradas literais. FAQ, SPAM, kernel ou home significam a mesma coisa em qualquer língua, todos entendem. Portanto ficam em <literal></literal>.
Expressões consagradas no Projeto também devem ser consideradas literais. Por exemplo, port, ports, Core Team, RELEASE não são fácilmente perceptíveis em qualquer língua, mas se o leitor conhece FreeBSD, em qualquer língua saberá à o que estas se referem. Portanto usaremos sempre <literal>ports</literal>, <literal>port</literal>, <literal>RELEASE</literal>, etc.
Mesmo com essas regras e dicas, ainda é possível cometermos erros sérios, nesse caso apenas o bom senso ou uma boa discussão pode evitar o desastre. Por exemplo, “port” pode levar ao desastre se traduzido errôneamente, e deve ser traduzido em outras circunstâncias. Digamos, se for o port de uma versão do FreeBSD, como port para Sparc64 não estamos falando de um <literal>port</literal>, esse se aplica à Coleção de Ports do FreeBSD. Estamos falando de uma conversão do FreeBSD. Nesse caso “port” deve ser traduzido como conversão, variação, etc. O que for melhor ao contexto. “Ports” podem também ser portas, ou pode ser porte. Porte em português vem de portar ou ter posse, como “porte de armas” ou “porte acionária”. É inaceitável “instalar a porta www/apache2” ou “instalar o porte www/apache2”. Da mesma forma é inaceitável dizer “verifique se a <literal>port</literal> 110 está aberta”.
Outro caso: UN*X-like é a denominação oficial para qualquer sistema que não pagou para passar na certificação UNIX ou que não paga direitos autorais para uso deste nome. Ou seja é um “UN*X-similar”. Melhor não traduzir, deixemos <foreignphrase>UN*X-like</foreignphrase>.
Em caso de dúvidas, e se a expressão já não está no glossário, pergunte na lista DOC-BR. Provavelmente a conclusão da discussão promovida será a inclusão da expressão no glossário.
Estas regras são um resumo do Primer do Projeto de Documentação do FreeBSD. Para cumpri-las como já vimos existem ferramentas no Projeto DOC-BR que nos auxiliam, mas caso alguém esteja esquecido delas no Primer do Projeto de Documentação do FreeBSD, aqui estão novamente.
Sempre substitua um conjunto de 8 espaços por um tab. Esta regra do Projeto é para evitar uso desnecessário de dados. Regra que existe em todo o Projeto FreeBSD, desde o sistema em sí até o Ports e FDP. O motivo é simples, 8 espaços e um tab tem a mesma disposição textual, mas 8 espaços ocupam 8 bytes enquanto um tab ocupa 1 byte.
Utilize sempre dois espaços após cada separador frasal.
Não utilize espaços depois da tag <para> e nem antes ou depois da tag </para>.
O parágrafo começa na mesma linha onde a tag <para> foi colocada.
Uma linha deve preferencialmente ter menos de 70 colunas, e obrigatóriamente menos de 84 colunas.
Quando um parágrafo for quebrado em várias linhas, as linhas que terminarem em palavras normais devem ter um espaço em branco no final, e as que terminarem em um separador frasal devem ter dois espaços.
As tags de mesmo tipo devem estar sempre no mesmo nível de identação.
Se as regras 1, 2, 3 e 4 não forem cumpridas o documento não é aceito no CVS do Projeto FreeBSD. Isso é uma verificação automática. As outras regras são sujeitas à análise e revisão humana.
Importante: Jamais, sob qualquer circunstância traduza nada com tradutores eletrônicos. Use-os se necessário apenas para consultas quanto à palavras independentes. Não use sequer para traduzir expressões sem antes consultar o resultado com o restante do time. Tradutores eletrônico nunca interpretam textos e contextos. Não há qualquer hipótese de seu resultado ser aceitável.
No passado contribuidores da DOC-BR chegaram a usar parágrafos inteiros como traduzidos eletrônicamente. O resultados é que estes textos tiveram que ser totalmente rescritos na revisão, e retraduzidos do inglês pois o resultado em português raramente podia ser compreendido dentro do contexto desejado. Isso gera retrabalho, desperdiça o tempo do tradutor e do revisor.
Qualquer dúvida durante o trabalho, não pense duas vezes, pergunte ao restante do time na lista.
Este, e outros documentos, podem ser obtidos em ftp://ftp.FreeBSD.org/pub/FreeBSD/doc/.
Para perguntas sobre FreeBSD, leia a documentação antes de contatar <questions@FreeBSD.org>.
Para perguntas sobre esta documentação, envie e-mail para <doc@FreeBSD.org>.