From nobody Sun Apr 30 09:04:05 2023 X-Original-To: dev-commits-doc-all@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4Q8L4Q3C9Kz46Xfw for ; Sun, 30 Apr 2023 09:04:06 +0000 (UTC) (envelope-from git@FreeBSD.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Q8L4Q158sz3yf6; Sun, 30 Apr 2023 09:04:06 +0000 (UTC) (envelope-from git@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1682845446; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=Q5bKx/rXe+HHcvh6WPcKnUPZ+XzGHUNsWxUOJAnFdkA=; b=JiscA3h7o/niYB+7o89A5mMpdbR8Tx3zRFeSSnmkmjT0KzHWhT6WRzCVwyuyswq5SAoRLu NQ6RHHvJ16/IzPVQtAHbuA6T1BPdTZelMuvSLXuF/KuApJlr4Be8kaVCtXbm/t3QoeUS11 dAxD3XLjGg3QTgNfMnBB7DyhvNDGxHfI/BW3NSCj672kmavuPBrCn+DSV92gkoCBFFqVNK UBw7R1LqLcvkIGbEtyC3QhPDtX846VgX7+WDd5eiR4TABFMH4ixXPuU9Wm61KR26sBkA1q xp1XQomKiJT7uV7uQ8uLD6gaRopJ3/5ANnyFznr+djGggK4Alm8X+l87klR1QA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1682845446; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=Q5bKx/rXe+HHcvh6WPcKnUPZ+XzGHUNsWxUOJAnFdkA=; b=Q9zXwXmnIE4bnfpc32X89/VEBQyjzzpfC3hWvDPE/K62+2aRqplYL9f8kUDwgQXhPmmHaw tL6SKQP5vHFwlAmW5WHAcLsSa5GHvOr6udhxEv7Atje3pZDjfxL1ZbrkZ143h9wW08iZ88 o0BoUMSIcMF1lyJGIOZF76c0gEJg3fY6VP5a/MfQ4NFAuofilfhZ6/Qp6NWzbdu1qQjMuo NGqkBgp+1M75Xk0yVRCaOj0MU+hPgg0BgwizBrmJEDAyvPyTpfLmFDswDgWEbV2xtQAKhO YF6P2pmGYgq7PoPah3/1v4Hgctw0oLyZCwtlTg332VlCLPkYKvTr4S2jFfgzCg== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1682845446; a=rsa-sha256; cv=none; b=BSesNMcpABYYelmn6d9VfMyz0yrs6uqygA3A7ILK8yFtXQW7MfVzw7LR9PICAd5jr/ZZ2l gGCkK0ou9J++AfI+P3U7NwdIDaozqt7uIDXWYuT1F4NX5jiaJuFI5UD5MCtnJ6k2+X03zo F2IA69xMkUYj2uA/E6fgrDLc1gxwsivrzVWrTDBRVeZz5y1K5GJIwckJ8VTbniJc0EYtYB EV6S6F7MlySrhrm0b+rwsip+0icPSnmhxhhKGf9W1z2i2wOzl4TrvhI5zdQVGeRzZoPgMz 88vI/hAfeboeEpr6yGsewzeho+kgvTiIViiGk0FDvAHEVWhBxhNlamNVBRUIMA== Received: from gitrepo.freebsd.org (gitrepo.freebsd.org [IPv6:2610:1c1:1:6068::e6a:5]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 4Q8L4Q088DzHlG; Sun, 30 Apr 2023 09:04:06 +0000 (UTC) (envelope-from git@FreeBSD.org) Received: from gitrepo.freebsd.org ([127.0.1.44]) by gitrepo.freebsd.org (8.16.1/8.16.1) with ESMTP id 33U945iw086394; Sun, 30 Apr 2023 09:04:05 GMT (envelope-from git@gitrepo.freebsd.org) Received: (from git@localhost) by gitrepo.freebsd.org (8.16.1/8.16.1/Submit) id 33U945oI086393; Sun, 30 Apr 2023 09:04:05 GMT (envelope-from git) Date: Sun, 30 Apr 2023 09:04:05 GMT Message-Id: <202304300904.33U945oI086393@gitrepo.freebsd.org> To: doc-committers@FreeBSD.org, dev-commits-doc-all@FreeBSD.org From: Edson Brandi Subject: git: e310196197 - main - Article rc-scripting translated to pt_BR and synced with doc tree version 98c736dd127a2096dc08252d1082300f2ec28ab5 List-Id: Commit messages for all branches of the doc repository List-Archive: https://lists.freebsd.org/archives/dev-commits-doc-all List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-dev-commits-doc-all@freebsd.org X-BeenThere: dev-commits-doc-all@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Git-Committer: ebrandi X-Git-Repository: doc X-Git-Refname: refs/heads/main X-Git-Reftype: branch X-Git-Commit: e31019619775d5a2622bfa65974ed9ac8901ce66 Auto-Submitted: auto-generated X-ThisMailContainsUnwantedMimeParts: N The branch main has been updated by ebrandi: URL: https://cgit.FreeBSD.org/doc/commit/?id=e31019619775d5a2622bfa65974ed9ac8901ce66 commit e31019619775d5a2622bfa65974ed9ac8901ce66 Author: Edson Brandi AuthorDate: 2023-04-30 09:02:52 +0000 Commit: Edson Brandi CommitDate: 2023-04-30 09:02:52 +0000 Article rc-scripting translated to pt_BR and synced with doc tree version 98c736dd127a2096dc08252d1082300f2ec28ab5 --- .../pt-br/articles/rc-scripting/_index.adoc | 238 +- .../content/pt-br/articles/rc-scripting/_index.po | 2337 ++++++++++++++++++++ 2 files changed, 2464 insertions(+), 111 deletions(-) diff --git a/documentation/content/pt-br/articles/rc-scripting/_index.adoc b/documentation/content/pt-br/articles/rc-scripting/_index.adoc index 2f4e667517..786fc7b14d 100644 --- a/documentation/content/pt-br/articles/rc-scripting/_index.adoc +++ b/documentation/content/pt-br/articles/rc-scripting/_index.adoc @@ -1,13 +1,16 @@ --- -title: Scripts rc.d práticos no BSD authors: - - author: Yar Tikhiy + - + author: 'Yar Tikhiy' email: yar@FreeBSD.org -copyright: 2005-2006, 2012 The FreeBSD Project +copyright: '2005-2006, 2012 The FreeBSD Project' +description: 'Um guia para escrever novos scripts rc.d e entender aqueles que já existem' +tags: ["rc.d", "scripting", "guide", "tutorial", "FreeBSD"] +title: 'Scripting rc.d na prática no BSD' trademarks: ["freebsd", "netbsd", "general"] --- -= Scripts rc.d práticos no BSD += Scripting rc.d na prática no BSD :doctype: article :toc: macro :toclevels: 1 @@ -41,7 +44,7 @@ endif::[] [.abstract-title] Resumo -Os iniciantes podem achar difícil relacionar os fatos da documentação formal do framework [.filename]#rc.d# do BSD com as tarefas práticas do script [.filename]#rc.d#. Neste artigo, consideramos alguns casos típicos de complexidade crescente, vamos mostrar os recursos do [.filename]#rc.d# adequados para cada caso e vamos discutir como eles funcionam. Esse exame deve fornecer pontos de referência para um estudo mais aprofundado do design e da aplicação eficiente do [.filename]#rc.d#. +Os iniciantes podem achar difícil relacionar os fatos da documentação formal sobre o framework [.filename]#rc.d# do BSD com as tarefas práticas de escrever scripts [.filename]#rc.d#. Neste artigo, consideramos alguns casos típicos de crescente complexidade, mostramos recursos do [.filename]#rc.d# adequados para cada caso e discutimos como eles funcionam. Essa análise deve fornecer pontos de referência para estudos posteriores do design e aplicação eficiente do [.filename]#rc.d#. ''' @@ -50,26 +53,26 @@ toc::[] [[rcng-intro]] == Introdução -Historicamente o BSD tinha um script de inicialização monolítico, o [.filename]#/etc/rc#. Ele era chamado pelo man:init[8] no momento da inicialização do sistema e executava todas as tarefas necessárias para a operação multi-usuário: verificação e montagem do sistemas de arquivos, configuração de rede, iniciava daemons e assim por diante. A lista precisa de tarefas não era a mesma em todos os sistemas; os administradores precisavam personalizá-lo. Com poucas exceções, o [.filename]#/etc/rc# teve que ser modificado, e os verdadeiros hackers gostaram disso. +No histórico BSD, havia um script de inicialização monolítico, [.filename]#/etc/rc#. Ele era invocado pelo man:init[8] no momento da inicialização do sistema e realizava todas as tarefas de usuário necessárias para a operação multiusuário: verificação e montagem de sistemas de arquivos, configuração da rede, inicialização de daemons e assim por diante. A lista precisa de tarefas não era a mesma em todos os sistemas; os administradores precisavam personalizá-la. Com poucas exceções, o [.filename]#/etc/rc# tinha que ser modificado, e os verdadeiros hackers gostavam disso. -O problema real com a abordagem monolítica era que ela não fornecia nenhum controle sobre os componentes individuais iniciados a partir do [.filename]#/etc/rc#. Por exemplo, o [.filename]#/etc/rc# não podia reiniciar um único daemon. O administrador do sistema tinha que encontrar o processo daemon manualmente, matá-lo, esperar até que ele realmente finalizasse, então procurar pelas flags no [.filename]#/etc/rc#, e finalmente digitar a linha de comando completa para iniciar o daemon novamente. A tarefa se tornaria ainda mais difícil e propensa a erros se o serviço de reinicialização consistisse em mais de um daemon ou exigisse ações adicionais. Em poucas palavras, o único script não cumpriu o objetivo dos scripts: tornar a vida do administrador do sistema mais fácil. +O problema real com a abordagem monolítica era que ela não fornecia controle sobre os componentes individuais iniciados a partir do [.filename]#/etc/rc#. Por exemplo, o [.filename]#/etc/rc# não podia reiniciar um único daemon. O administrador do sistema tinha que encontrar o processo do daemon manualmente, matá-lo, aguardar até que ele realmente finalizasse, navegar por [.filename]#/etc/rc# em busca das flags e, finalmente, digitar a linha de comando completa para iniciar o daemon novamente. A tarefa se tornaria ainda mais difícil e propensa a erros se o serviço a ser reiniciado consistisse em mais de um daemon ou exigisse ações adicionais. Em poucas palavras, o script único falhou em cumprir o objetivo pelo qual um script é criado: tornar a vida do administrador do sistema mais fácil. -Mais tarde, houve uma tentativa de dividir algumas partes do [.filename]#/etc/rc# para iniciar os subsistemas mais importantes separadamente. O exemplo notório foi o [.filename]#/etc/netstart# para configurar a rede. Ele permitia acessar a rede a partir do modo single-user, mas não se integrou bem ao processo de inicialização automática porque partes de seu código precisavam intercalar com ações essencialmente não relacionadas à rede. Foi por isso que o [.filename]#/etc/netstart# mudou para [.filename]#/etc/rc.network#. Este último não era mais um script comum; ele era composto por um emaranhado de funções man:sh[1] chamadas pelo [.filename]#/etc/rc# em diferentes estágios da inicialização do sistema. No entanto, a medida que as tarefas de inicialização cresciam variadas e sofisticadas, a abordagem "quase modular" tornou-se ainda mais engessada do que o monolítico [.filename]#/etc/rc#. +Mais tarde, houve uma tentativa de dividir algumas partes do [.filename]#/etc/rc# para iniciar os subsistemas mais importantes separadamente. O exemplo notório foi o [.filename]#/etc/netstart# para iniciar a rede. Isso permitiu o acesso à rede no modo de usuário único, mas não se integrou bem ao processo de inicialização automática porque partes de seu código precisavam intercalar com ações essencialmente não relacionadas à rede. Foi por isso que o [.filename]#/etc/netstart# se transformou em [.filename]#/etc/rc.network#. Este último não era mais um script comum; era composto de grandes funções man:sh[1] complexas chamadas pelo [.filename]#/etc/rc# em diferentes estágios da inicialização do sistema. No entanto, à medida que as tarefas de inicialização ficaram mais diversas e sofisticadas, a abordagem "quase modular" tornou-se ainda mais pesada do que o monolítico [.filename]#/etc/rc# tinha sido. -Sem um framework limpo e bem projetado, os scripts de inicialização tiveram que se curvar para satisfazer as necessidades de desenvolvimento rápido dos sistemas operacionais baseados no BSD. Tornou-se óbvio, finalmente, que mais passos eram necessários no caminho para construção de um sistema [.filename]#rc# extensível e customizável. Assim nasceu o BSD [.filename]#rc.d#. Seus pais reconhecidos foram o Luke Mewburn e a comunidade do NetBSD. Mais tarde ele foi importado para o FreeBSD. Seu nome se refere à localização dos scripts do sistema para serviços individuais, que é o [.filename]#/etc/rc.d#. Em breve, vamos aprender sobre mais componentes do sistema [.filename]#rc.d# e vamos ver como os scripts individuais são invocados. +Sem um framework limpo e bem projetado, os scripts de inicialização tiveram que se dobrar para atender às necessidades dos sistemas operacionais baseados em BSD que estavam em rápida evolução. Tornou-se evidente, finalmente, que mais etapas eram necessárias para se chegar a um sistema [.filename]#rc# refinado, granular e extensível. Assim nasceu o [.filename]#rc.d# do BSD. Seus pais reconhecidos foram Luke Mewburn e a comunidade NetBSD. Mais tarde, foi importado para o FreeBSD. Seu nome se refere ao local dos scripts do sistema para serviços individuais, que está em [.filename]#/etc/rc.d#. Em breve, aprenderemos mais sobre os componentes do sistema [.filename]#rc.d# e veremos como os scripts individuais são invocados. -As idéias básicas por trás do BSD [.filename]#rc.d# são _modularidade fina_ e __reutilização de código__. _Modularidade fina_ significa que cada "serviço básico", como um daemon do sistema ou uma tarefa de inicialização primitiva, obtém seu próprio script man:sh[] capaz de iniciar o serviço, pará-lo, recarregá-lo e verificar seu status. Uma ação específica é escolhida pelo argumento da linha de comando para o script. O script [.filename]#/etc/rc# ainda comanda a inicialização do sistema, mas agora ele simplesmente invoca os scripts menores um por um com o argumento `start`. É fácil executar tarefas de desligamento executando o mesmo conjunto de scripts com o argumento `stop`, o que é feito pelo [.filename]#/etc/rc.shutdown#. Observe como isso segue de perto o modo Unix de ter um conjunto de pequenas ferramentas especializadas, cada uma cumprindo sua tarefa da melhor forma possível. _Reutilização de código_ significa que operações comuns são implementa das como funções man:sh[1] e coletadas em [.filename]#/etc/rc.subr#. Agora, um script típico pode conter apenas algumas linhas de código man:sh[1]. Finalmente, uma parte importante do framework do [.filename]#rc.d# é man:rcorder[8], o qual ajuda o [.filename]#/etc/rc# a executar os pequenos scripts ordenadamente em relação às dependências entre eles. Ele também pode ajudar o [.filename]#/etc/rc.shutdown#, porque a ordem apropriada para a sequência de encerramento é oposta à da inicialização. +As ideias básicas por trás do [.filename]#rc.d# do BSD são _modularidade fina_ e __reutilização de código__. _Modularidade fina_ significa que cada "serviço" básico, como um daemon do sistema ou uma tarefa de inicialização primitiva, possui seu próprio script man:sh[1] capaz de iniciar o serviço, pará-lo, recarregá-lo e verificar seu status. Uma ação específica é escolhida pelo argumento da linha de comando do script. O script [.filename]#/etc/rc# ainda conduz a inicialização do sistema, mas agora ele apenas invoca os scripts menores um por um com o argumento `start`. Também é fácil realizar tarefas de desligamento executando o mesmo conjunto de scripts com o argumento `stop`, que é feito por [.filename]#/etc/rc.shutdown#. Observe como isso segue de perto a maneira Unix de ter um conjunto de ferramentas especializadas pequenas, cada uma cumprindo sua tarefa da melhor maneira possível. _Reutilização de código_ significa que operações comuns são implemen tadas como funções man:sh[1] e coletadas em [.filename]#/etc/rc.subr#. Agora, um script típico pode ser composto apenas de algumas linhas de código man:sh[1]. Finalmente, uma parte importante do framework [.filename]#rc.d# é o man:rcorder[8], que ajuda o [.filename]#/etc/rc# a executar os pequenos scripts de maneira ordenada com respeito às dependências entre eles. Isso também pode ajudar o [.filename]#/etc/rc.shutdown#, porque a ordem apropriada para a sequência de desligamento é oposta à de inicialização. -O design do BSD [.filename]#rc.d# é descrito no <>, e os componentes do [.filename]#rc.d# são documentados em grande detalhe nas <>. No entanto, pode não parecer óbvio para um novato em [.filename]#rc.d# como amarrar os inúmeros pedaços juntos para criar um script bem estilizado para uma tarefa específica. Portanto, este artigo tentará uma abordagem diferente para descrever o [.filename]#rc.d#. Ele mostrará quais recursos devem ser usados em vários casos típicos e por quê. Note que este não é um documento explicativo porque nosso objetivo não é fornecer receitas prontas, mas mostrar algumas entradas fáceis no domínio do [.filename]#rc.d#. Nem este artigo é um substituto para as páginas de manual relevantes. Não hesite em consultá-los para obter uma documentação mais formal e completa ao ler este artigo. +O design do BSD [.filename]#rc.d# é descrito no <>, e os componentes do [.filename]#rc.d# são documentados em grande detalhe nas <>. No entanto, pode não ser óbvio para um iniciante no [.filename]#rc.d# como ele deve unir as numerosas partes para criar um script bem estruturado para uma tarefa específica. Portanto, este artigo tentará abordar o [.filename]#rc.d# de forma diferente. Mostrará quais recursos devem ser usados em vários casos típicos e por que. Observe que este não é um documento de "como fazer", porque nosso objetivo não é fornecer receitas prontas, mas mostrar algumas entradas fáceis no mundo do [.filename]#rc.d#. Este artigo também não substitui as páginas do manual relevantes. Não hesite em consultá-las para obter documentação mais formal e completa enquanto lê este artigo. -Existem pré-requisitos para entender este artigo. Primeiro de tudo, você deve estar familiarizado com a linguagem de script man:sh[1] para poder dominar o [.filename]#rc.d#. Além disso, você deve saber como o sistema executa as tarefas de inicialização e encerramento do userland, o que está descrito em man:rc[8]. +Existem pré-requisitos para entender este artigo. Em primeiro lugar, você deve estar familiarizado com a linguagem de script man:sh[1] para dominar o [.filename]#rc.d#. Além disso, você deve saber como o sistema realiza tarefas de inicialização e desligamento do espaço do usuário, o que é descrito em man:rc[8]. -Este artigo foca no branch [.filename]#rc.d# do FreeBSD. No entanto, ele também pode ser útil para os desenvolvedores do NetBSD, porque os dois branchs [.filename]#rc.d# do BSD não apenas compartilham o mesmo design, mas também permanecem similares em seus aspectos visíveis aos autores do script. +Este artigo foca no ramo do FreeBSD do [.filename]#rc.d#. No entanto, ele pode ser útil também para desenvolvedores do NetBSD, pois os dois ramos do [.filename]#rc.d# não apenas compartilham o mesmo design, mas também permanecem similares em seus aspectos visíveis aos autores de scripts. [[rcng-task]] == Esboçando a tarefa -Um pouco de consideração antes de iniciar o `$EDITOR` não irá prejudicar. Para escrever um script [.filename]#rc.d# corretamente customizado para um serviço do sistema, devemos poder responder as seguintes questões primeiro: +Uma pequena reflexão antes de iniciar o `$EDITOR` não fará mal. Para escrever um script [.filename]#rc.d# bem elaborado para um serviço do sistema, devemos ser capazes de responder às seguintes perguntas primeiro: * O serviço é obrigatório ou opcional? * O script servirá um único programa, por exemplo, um daemon, ou realizará ações mais complexas? @@ -101,67 +104,67 @@ load_rc_config $name <.> run_rc_command "$1" <.> .... -Os pontos a serem observadas são: +Os pontos a serem observados são: -➊ Um script interpretado deve começar com a linha mágica "shebang". Essa linha especifica o programa interpretador para o script. Devido a linha shebang, o script pode ser invocado exatamente como um programa binário, desde que tenha o bit de execução definido. (Veja man:chmod[1].) Por exemplo, um administrador do sistema pode executar nosso script manualmente, a partir da linha de comando: +➊ Um script interpretado deve começar com a linha mágica "shebang". Essa linha especifica o programa interpretador para o script. Devido à linha shebang, o script pode ser invocado exatamente como um programa binário, desde que tenha o bit de execução definido. (Veja man:chmod[1].) Por exemplo, um administrador do sistema pode executar nosso script manualmente, a partir da linha de comando: -[source,shell] +[source, shell] .... # /etc/rc.d/dummy start .... [NOTE] ==== -Para ser adequadamente gerenciado pelo framework do [.filename]#rc.d#, seus scripts precisam ser escritos na linguagem man:sh[1]. Se você tiver um serviço ou port que use um utilitário de controle binário ou uma rotina de inicialização escrita em outra linguagem, instale este elemento em [.filename]#/usr/sbin# (para o sistema) ou em [.filename]#/usr/local/sbin# (para um port) e invoque-o por meio de um script man:sh[1] no diretório apropriado do [.filename]#rc.d#. +Para ser gerenciado corretamente pelo framework [.filename]#rc.d#, os scripts devem ser escritos na linguagem man:sh[1]. Se você tiver um serviço ou port que usa um utilitário de controle binário ou uma rotina de inicialização escrita em outra linguagem, instale esse elemento em [.filename]#/usr/sbin# (para o sistema) ou [.filename]#/usr/local/sbin# (para ports) e chame-o a partir de um script man:sh[1] no diretório [.filename]#rc.d# apropriado. ==== [TIP] ==== -Caso você queira aprender os detalhes do porque os scripts [.filename]#rc.d# devem ser escritos na linguagem man:sh[1], veja como o [.filename]#/etc/rc# invoca-os por meio de `run_rc_script`, e então estude a implementação de `run_rc_script` em [.filename]#/etc/rc. subr#. +Se você gostaria de aprender os detalhes de por que os scripts [.filename]#rc.d# devem ser escritos na linguagem man:sh[1], veja como o [.filename]#/etc/rc# os invoca por meio de `run_rc_script` e, em seguida, estude a implementação de `run_rc_script` em [.filename]#/etc/rc.subr#. ==== -➋ Em [.filename]#/etc/rc.subr#, várias funções man:sh[1] estão definidas para serem utilizadas por um script [.filename]#rc.d#. As funções estão documentadas em man:rc.subr[8]. Embora seja teoricamente possível escrever um script [.filename]#rc.d# sem usar o man:rc.subr[8], as suas funções são extremamente úteis e tornam o trabalho mais fácil. Portanto, não é de surpreender que todos recorram a scripts man:rc.subr[8] em [.filename]#rc.d#. Nós não vamos ser uma exceção. +➋ Em [.filename]#/etc/rc.subr#, uma série de funções man:sh[1] estão definidas para serem utilizadas por um script [.filename]#rc.d#. As funções estão documentadas em man:rc.subr[8]. Embora seja teoricamente possível escrever um script [.filename]#rc.d# sem nunca usar o man:rc.subr[8], suas funções provam ser extremamente úteis e tornam o trabalho uma ordem de magnitude mais fácil. Portanto, não é surpresa que todo mundo recorra ao man:rc.subr[8] em scripts [.filename]#rc.d#. Não seremos uma exceção. -Um script [.filename]#rc.d# deve "incluir" o [.filename]#/etc/rc.subr# (isto por ser feito usando o comando "`.`") _antes_ que ele chame as funções do man:rc.subr[8] para que o man:sh[1] tenha a oportunidade para aprender as funções. O estilo preferido é incluir o [.filename]#/etc/rc.subr# antes de tudo. +Um script [.filename]#rc.d# deve fazer o "source" do [.filename]#/etc/rc.subr# (inclua-o usando "`.`") _antes_ de chamar as funções man:rc.subr[8] para que o man:sh[1] tenha a oportunidade de aprender as funções. O estilo preferido é incluir o [.filename]#/etc/rc.subr# antes de tudo. [NOTE] ==== -Algumas funções úteis relacionadas a rede são fornecidas por outro arquivo include, o [.filename]#/etc/network.subr#. +Algumas funções úteis relacionadas à rede são fornecidas por outro arquivo de inclusão, o [.filename]#/etc/network.subr#. ==== -➌ [[name-var]]A variável obrigatória `name` especifica o nome do nosso script. Ela é exigida pelo man:rc.subr[8]. Ou seja, cada script [.filename]#rc.d# __deve__ definir a variável `name` antes de chamar funções do man:rc.subr[8]. +➌ A variável obrigatória `name` especifica o nome do nosso script. Ela é exigida pelo man:rc.subr[8]. Isso significa que cada script [.filename]#rc.d# _deve_ definir `name` antes de chamar funções do man:rc.subr[8]. Agora é o momento certo para escolher um nome exclusivo para o nosso script de uma vez por todas. Vamos usá-lo em vários lugares enquanto desenvolvemos o script. Para começar, também vamos dar o mesmo nome ao arquivo de script. [NOTE] ==== -O estilo atual do script [.filename]#rc.d# é incluir valores atribuídos as variáveis entre aspas duplas. Tenha em mente que é apenas um problema de estilo que nem sempre pode ser aplicável. Você pode omitir com segurança as aspas das palavras simples sem os metacaracteres do man:sh[1] nelas, enquanto em certos casos você precisará de aspas simples para evitar qualquer interpretação do valor pelo man:sh[1]. Um programador deve ser capaz de dizer a sintaxe da linguagem a partir das convenções de estilo e bem como de usá-las sabiamente. +O estilo atual de escrita de scripts [.filename]#rc.d# é envolver os valores atribuídos às variáveis em aspas duplas. Tenha em mente que isso é apenas uma questão de estilo que nem sempre é aplicável. Você pode seguramente omitir as aspas ao redor de palavras simples sem metacaracteres man:sh[1], enquanto em certos casos você precisará de aspas simples para evitar qualquer interpretação do valor por man:sh[1]. Um programador deve ser capaz de distinguir a sintaxe da linguagem das convenções de estilo e usá-las sabiamente. ==== -➍ A idéia principal por trás do man:rc.subr[8] é que um script [.filename]#rc.d# fornece manipuladores, ou métodos, para o man:rc.subr[8] invocar. Em particular, `start`, `stop` e outros argumentos para um script [.filename]#rc.d# são tratados desta maneira. Um método é uma expressão man:sh[1] armazenada em uma variável denominada `argument_cmd`, no qual _argument_ corresponde ao que pode ser especificado na linha de comando do script. Vamos ver mais adiante como o man:rc.subr[8] fornece métodos default para os argumentos padrão. +➍ Cada script [.filename]#rc.d# fornece manipuladores, ou métodos, para o man:rc.subr[8] invocar. Em particular, `start`, `stop`, e outros argumentos para um script [.filename]#rc.d# são manipulados desta forma. Um método é uma expressão man:sh[1] armazenada em uma variável chamada `argument_cmd`, onde _argument_ corresponde ao que pode ser especificado na linha de comando do script. Veremos mais tarde como o man:rc.subr[8] fornece métodos padrão para os argumentos padrão. [NOTE] ==== -Para tornar o código em [.filename]#rc.d# mais uniforme, é comum usar `${name}` onde for apropriado. Assim, várias linhas podem ser copiadas de um script para outro. +Para tornar o código em [.filename]#rc.d# mais uniforme, é comum usar `${name}` sempre que apropriado. Assim, várias linhas podem ser simplesmente copiadas de um script para outro. ==== -➎ Devemos ter em mente que o man:rc.subr[8] fornece métodos default para os argumentos padrões. Consequentemente, devemos sobrescrever um método default com uma expressão no-op man:sh[] se desejarmos que ele não faça nada. +➎ Devemos ter em mente que o man:rc.subr[8] fornece métodos padrões para os argumentos padrões. Consequentemente, devemos substituir um método padrão por uma expressão man:sh[1] sem efeito se quisermos que ele não faça nada. -➏ O corpo de um método sofisticado pode ser implementado como uma função. É uma boa ideia tornar o nome da função significativo. +➏ O corpo de um método sofisticado pode ser implementado como uma função. É uma boa ideia dar um nome significativo à função. [IMPORTANT] ==== -É altamente recomendado adicionar o prefixo `${name}` aos nomes de todas as funções definidas em nosso script, para que eles nunca entrem em conflito com as funções do man:rc.subr[8] ou outro arquivo de inclusão comum. +Recomenda-se fortemente adicionar o prefixo `${name}` aos nomes de todas as funções definidas no nosso script para que nunca entrem em conflito com as funções de man:rc.subr[8] ou outro arquivo de inclusão comum. ==== -➐ Essa chamada ao man:rc.subr[8] carrega as variáveis do man:rc.conf[5]. Nosso script não faz uso delas ainda, mas ainda assim é recomendado carregar o man:rc.conf[5] pois podem haver variáveis man:rc.conf[5] controlando o man:rc.subr[8] propriamente dito. +➐ Essa chamada para o man:rc.subr[8] carrega as variáveis do man:rc.conf[5]. Nosso script ainda não as usa, mas ainda é recomendável carregar o man:rc.conf[5] porque pode haver variáveis do man:rc.conf[5] controlando o man:rc.subr[8] em si. -➑ Geralmente este é o último comando em um script [.filename]#rc.d#. Ele invoca o maquinário man:rc.subr[8] para executar a ação solicitada usando as variáveis e métodos que nosso script forneceu. +➑ Geralmente, esse é o último comando em um script [.filename]#rc.d#. Ele invoca a maquinaria do man:rc.subr[8] para realizar a ação solicitada usando as variáveis e métodos que o nosso script forneceu. [[rcng-confdummy]] == Um script fictício configurável -Agora vamos adicionar alguns controles ao nosso script fictício. Como você deve saber, os scripts [.filename]#rc.d# são controlados pelo man:rc.conf[5]. Felizmente, o man:rc.subr[8] esconde todas as complicações de nós. O script a seguir usa o man:rc.conf[5] via man:rc.subr[8] para ver se ele está habilitado em primeiro lugar, e buscar uma mensagem para mostrar no momento da inicialização. Estas duas tarefas são de fato independentes. Por um lado, um script [.filename]#rc.d# pode apenas suportar a ativação e desativação de seu serviço. Por outro lado, um script [.filename]#rc.d# obrigatório pode ter variáveis de configuração. Nós vamos fazer as duas coisas no mesmo script: +Agora vamos adicionar alguns controles ao nosso script fictício. Como você deve saber, scripts [.filename]#rc.d# são controlados com o man:rc.conf[5]. Felizmente, o man:rc.subr[8] oculta todas as complicações para nós. O script a seguir usa o man:rc.conf[5] por meio do man:rc.subr[8] para verificar se está habilitado em primeiro lugar e para buscar uma mensagem para ser exibida na inicialização. Essas duas tarefas, na verdade, são independentes. Por um lado, um script [.filename]#rc.d# pode apenas suportar a habilitação e desabilitação do seu serviço. Por outro lado, um script [.filename]#rc.d# obrigatório pode ter variáveis de configuração. No entanto, faremos as duas coisas no mesmo script: [.programlisting] .... @@ -189,43 +192,43 @@ run_rc_command "$1" O que mudou neste exemplo? -➊ A variável `rcvar` especifica o nome da variável do botão ON/OFF. +➊ A variável `rcvar` especifica o nome da variável do botão LIGA/DESLIGA. -➋ Agora o `load_rc_config` é invocado anteriormente no script, antes que qualquer variável do man:rc.conf[5] seja acessada. +➋ Agora, o `load_rc_config` é invocado mais cedo no script, antes que quaisquer variáveis do man:rc.conf[5] sejam acessadas. [NOTE] ==== -Ao examinar os scripts [.filename]#rc.d#, tenha em mente que o man:sh[1] adia a avaliação de expressões em uma função até que a função seja chamada. Portanto, não é um erro invocar `load_rc_config` tão tarde quanto antes do `run_rc_comman` e ainda acessar as variáveis do man:rc.conf[5] a partir do método das funções exportadas para o `run_rc_command`. Isto ocorre porque as funções do método devem ser chamadas por `run_rc_command`, que é chamado _após_ o `load_rc_config`. +Enquanto examina os scripts [.filename]#rc.d#, tenha em mente que o man:sh[1] adia a avaliação de expressões em uma função até que esta seja chamada. Portanto, não é um erro invocar `load_rc_config` tão tarde quanto logo antes de `run_rc_command` e ainda assim acessar as variáveis man:rc.conf[5] das funções de método exportadas para `run_rc_command`. Isso ocorre porque as funções de método devem ser chamadas por `run_rc_command`, que é invocado _após_ `load_rc_config`. ==== -➌ Um aviso será emitido pelo `run_rc_command` se o próprio `rcvar` estiver definido, mas a variável de knob indicada não estiver definida. Se o seu script [.filename]#rc.d# for para o sistema base, você deve adicionar uma configuração padrão para o knob no [.filename]#/etc/defaults/rc.conf# e documentá-lo em man:rc.conf[5]. Caso contrário, será o seu script que deverá fornecer uma configuração padrão para o knob. A abordagem canônica para o último caso é mostrada no exemplo. +➌ Aviso será emitido pelo `run_rc_command` se o `rcvar` em si estiver configurado, mas a variável de controle indicada estiver desativada. Se o seu script [.filename]#rc.d# é para o sistema base, você deve adicionar uma configuração padrão para o knob em [.filename]#/etc/defaults/rc.conf# e documentá-lo em man:rc.conf[5]. Caso contrário, é seu script que deve fornecer uma configuração padrão para o knob. A abordagem canônica para o último caso é mostrada no exemplo. [NOTE] ==== -Você pode fazer o man:rc.subr[8] agir como se o knob fosse definido como `ON`, independentemente da sua configuração atual, prefixando o argumento para o script com `one` ou `force`, como em `onestart` ou `forcestop`. Tenha em mente que o `force` tem outros efeitos perigosos que mencionaremos abaixo, enquanto `one` apenas sobrescreve o knob ON/OFF. Por exemplo, suponha que `dummy_enable` seja `OFF`. O comando a seguir executará o método `start` apesar da configuração: +Você pode fazer o man:rc.subr[8] agir como se o botão estivesse definido como `ON`, independentemente de sua configuração atual, prefixando o argumento do script com `one` ou `force`, como em `onestart` ou `forcestop`. No entanto, tenha em mente que `force` tem outros efeitos perigosos que abordaremos abaixo, enquanto `one` apenas substitui o botão ON/OFF. Por exemplo, suponha que `dummy_enable` esteja definido como `OFF`. O seguinte comando executará o método `start` apesar da configuração: -[source,shell] +[source, shell] .... # /etc/rc.d/dummy onestart .... ==== -➍ Agora, a mensagem a ser mostrada no momento da inicialização não é mais codificada no script. Ela é especificada por uma variável do man:rc.conf[5] chamada `dummy_msg`. Este é um exemplo trivial de como as variáveis do man:rc.conf[5] podem controlar um script [.filename]#rc.d#. +➍ Agora a mensagem a ser exibida na inicialização não é mais codificada no script. É especificada por uma variável man:rc.conf[5] chamada `dummy_msg`. Este é um exemplo trivial de como as variáveis man:rc.conf[5] podem controlar um script [.filename]#rc.d#. [IMPORTANT] ==== -Os nomes de todas as variáveis do man:rc.conf[5] usadas exclusivamente pelo nosso script _devem_ possuir o mesmo prefixo: `${name}_`. Por exemplo: `dummy_mode`, `dummy_state_file`, e assim por diante. +Os nomes de todas as variáveis man:rc.conf[5] usadas exclusivamente pelo nosso script _devem_ ter o mesmo prefixo: `${name}_`. Por exemplo: `dummy_mode`, `dummy_state_file`, e assim por diante. ==== [NOTE] ==== -Embora seja possível usar um nome mais curto internamente, por exemplo, apenas `msg`, adicionar o prefixo exclusivo `${name}_` a todos os nomes globais introduzidos pelo nosso script nos salvará de possíveis colisões com o nome das funções existentes no man:rc.subr[8]. +Embora seja possível usar um nome mais curto internamente, por exemplo, apenas `msg`, adicionar o prefixo único `${name}_` a todos os nomes globais introduzidos pelo nosso script nos salvará de possíveis colisões com o namespace do man:rc.subr[8]. -Como regra, os scripts [.filename]#rc.d# do sistema base não precisam fornecer valores padrões para as suas variáveis man:rc.conf[5] porque os padrões devem ser definidos em [.filename]#/etc/defaults/rc.conf#. Por outro lado, os scripts [.filename]#rc.d# para os ports devem fornecer os valores padrões, conforme mostrado no exemplo. +Como regra geral, os scripts [.filename]#rc.d# do sistema base não precisam fornecer valores padrão para suas variáveis man:rc.conf[5], pois os valores padrão devem ser definidos em [.filename]#/etc/defaults/rc.conf#. Por outro lado, os scripts [.filename]#rc.d# para ports devem fornecer os valores padrão conforme mostrado no exemplo. ==== -➎ Aqui usamos `dummy_msg` para realmente controlar nosso script, ou seja, para emitir uma mensagem variável. O uso de uma função de shell é um exagero aqui, já que ele só executa um único comando; uma alternativa igualmente válida seria: +➎ Aqui usamos `dummy_msg` para controlar nosso script, ou seja, para emitir uma mensagem variável. O uso de uma função shell é excessivo aqui, uma vez que ela executa apenas um único comando; uma alternativa igualmente válida é: [.programlisting] .... @@ -235,7 +238,7 @@ start_cmd="echo \"$dummy_msg\"" [[rcng-daemon]] == Inicialização e desligamento de um daemon simples -Dissemos anteriormente que o man:rc.subr[8] poderia fornecer métodos padrão. Obviamente, estes padrões não podem ser muito gerais. Eles são adequados para o caso comum de iniciar e encerrar um programa daemon simples. Vamos supor agora que precisamos escrever um script [.filename]#rc.d# para um daemon chamado `mumbled`. Aqui está: +Dissemos anteriormente que o man:rc.subr[8] pode fornecer métodos padrões. Obviamente, tais padrões não podem ser muito gerais. Eles são adequados para o caso comum de iniciar e desligar um programa de daemon simples. Vamos supor agora que precisamos escrever um script [.filename]#rc.d# para um daemon chamado `mumbled`. Aqui está: [.programlisting] .... @@ -254,20 +257,20 @@ run_rc_command "$1" Agradavelmente simples, não é? Vamos examinar nosso pequeno script. A única coisa nova a observar é o seguinte: -➊ A variável `command` é significativa para o man:rc.subr[8]. Se estiver definido, o man:rc.subr[8] agirá de acordo com o cenário de servir um daemon convencional. Em particular, os métodos padrão serão fornecidos para tais argumentos: `start`, `stop`, `restart`, `poll`, e `status`. +➊ A variável `command` é significativa para man:rc.subr[8]. Se ela estiver definida, man:rc.subr[8] agirá de acordo com o cenário de servir a um daemon convencional. Em particular, os métodos padrão serão fornecidos para esses argumentos: `start`, `stop`, `restart`, `poll` e `status`. -O daemon será iniciado executando `$command` com os sinalizadores de linha de comando especificados por `$mumbled_flags`. Assim, todos os dados de entrada para o método padrão `start` estão disponíveis nas variáveis configuradas pelo nosso script. Ao contrário do `start`, outros métodos podem requerer informações adicionais sobre o processo iniciado. Por exemplo, `stop` deve conhecer o PID do processo para terminá-lo. No presente caso, man:rc.subr[8]varrerá a lista de todos os processos, procurando por um processo com seu nome igual a `$procname`. Esta última é outra variável de significado para man:rc.subr[8], e seu valor é padronizado para `command`. Em outras palavras, quando definimos o `command`, `procname` é efetivamente definido para o mesmo valor. Isso permite que nosso script mate o daemon e verifique se ele está sendo executado em primeiro lugar. +O daemon será iniciado executando `$command` com as flags de linha de comando especificadas por `$mumbled_flags`. Assim, todos os dados de entrada para o método `start` padrão estão disponíveis nas variáveis definidas pelo nosso script. Ao contrário de `start`, outros métodos podem exigir informações adicionais sobre o processo iniciado. Por exemplo, `stop` deve saber o PID do processo para terminá-lo. No caso presente, man:rc.subr[8] irá pesquisar a lista de todos os processos, procurando por um processo com o nome igual a `procname`. Este último é outra variável com significado para man:rc.subr[8], e seu valor padrão é o de `command`. Em outras palavras, quando definimos `command`, `procname` é efetivamente definido para o mesmo valor. Isso permite que nosso script mate o daemon e verifique se ele está em execução. [NOTE] ==== -Alguns programas são, na verdade, scripts executáveis. O sistema executa esse script iniciando seu interpretador e passando o nome do script para ele como um argumento de linha de comando. Isso é refletido na lista de processos, que podem confundir o man:rc.subr[8]. Você também deve definir o `command_interpreter` para permitir que o man:rc.subr[8] saiba o nome real do processo se o `$command` é um script. +Algumas vezes, programas são de fato scripts executáveis. O sistema executa esse script iniciando o seu interpretador e passando o nome do script como um argumento na linha de comando. Isso é refletido na lista de processos, o que pode confundir man:rc.subr[8]. Você deve adicionalmente definir `command_interpreter` para que man:rc.subr[8] saiba o nome real do processo se `$command` for um script. -Para cada script [.filename]#rc.d#, existe uma variável man:rc.conf[] que tem precedência sobre `command`. Seu nome é construído da seguinte forma: `${name}_program`, onde `name` é a variável obrigatória que discutimos <>. Por exemplo, neste caso, será `mumbled_program`. É man:rc.subr[8] que organiza `${name}_program` para substituir o comando. +A cada script [.filename]#rc.d#, há uma variável opcional do man:rc.conf[5] que tem precedência sobre `command`. Seu nome é construído da seguinte forma: `${name}_program`, onde `name` é a variável obrigatória discutida anteriormente. Por exemplo, neste caso, será `mumbled_program`. É o man:rc.subr[8] que arruma `${name}_program` para substituir `command`. -Obviamente, o man:sh[1] permitirá que você defina `${name}_program` a partir do man:rc.conf[5] ou o próprio script, mesmo que o `command` esteja indefinido. Nesse caso, as propriedades especiais de `${name}_program` são perdidas e se tornam uma variável comum que seu script pode usar para seus próprios propósitos. No entanto, o uso exclusivo de `${name}_program` é desencorajado porque usá-lo junto com o `command` tornou-se um idioma na escrita de scripts [.filename]#rc.d#. +Claro que o man:sh[1] permite definir `${name}_program` a partir do man:rc.conf[5] ou do próprio script, mesmo se `command` não estiver definido. Nesse caso, as propriedades especiais de `${name}_program` são perdidas, e ela se torna uma variável comum que o script pode usar para seus próprios fins. No entanto, o uso exclusivo de `${name}_program` é desencorajado, pois usá-la em conjunto com `command` se tornou idiomático em [.filename]#rc.d# scripting. ==== -Para obter informações mais detalhadas sobre métodos padrões, consulte man:rc.subr[8]. +Para obter informações mais detalhadas sobre os métodos padrões, consulte man:rc.subr[8]. [[rcng-daemon-adv]] == Inicialização e desligamento de um daemon avançado @@ -288,7 +291,7 @@ command_args="mock arguments > /dev/null 2>&1" <.> pidfile="/var/run/${name}.pid" <.> -required_files="/etc/${name}.conf /usr/shared/misc/${name}.rules" <.> +required_files="/etc/${name}.conf /usr/share/misc/${name}.rules" <.> sig_reload="USR1" <.> @@ -330,75 +333,75 @@ load_rc_config $name run_rc_command "$1" .... -➊ Argumentos adicionais para `$command` podem ser passados em `command_args`. Eles serão adicionados a linha de comando após `$mumbled_flags`. Como a linha de comando final é passada para `eval` para sua execução real, os redirecionamentos de entrada e saída podem ser especificados em `command_args`. +➊ Argumentos adicionais para `$command` podem ser passados em `command_args`. Eles serão adicionados à linha de comando após `$mumbled_flags`. Como a linha de comando final é passada para `eval` para sua execução real, redirecionamentos de entrada e saída podem ser especificados em `command_args`. [NOTE] ==== -_Nunca_ inclua opções tracejadas, como `-X` ou `--foo`, em `command_args`. O conteúdo de `command_args` aparecerá no final da linha de comando final, portanto é provável que eles sigam os argumentos presentes em `${name}_flags`; mas a maioria dos comandos não reconhecerá opções tracejadas após argumentos comuns. Uma maneira melhor de passar opções adicionais para `$command` é adicioná-las ao início de `${name}_flags`. Outra maneira é modificar `rc_flags` <>. +_Nunca_ inclua opções com hífen, como `-X` ou `--foo`, em `command_args`. O conteúdo de `command_args` aparecerá no final da linha de comando final, portanto, é provável que sigam argumentos presentes em `${name}_flags`; mas a maioria dos comandos não reconhecerá opções com hífen após argumentos comuns. Uma maneira melhor de passar opções adicionais para `$command` é adicioná-las no início de `${name}_flags`. Outra maneira é modificar `rc_flags` <>. ==== -➋ Um daemon de boas maneiras deve criar um _pidfile_ para que seu processo possa ser encontrado com mais facilidade e confiabilidade. A variável `pidfile`, se configurada, informa ao man:rc.subr[8] onde pode encontrar o pidfile para seus métodos padrão possam usar. +➋ Um daemon bem comportado deve criar um _pidfile_ para que seu processo possa ser encontrado de forma mais fácil e confiável. A variável `pidfile`, se definida, informa ao man:rc.subr[8] onde ele pode encontrar o pidfile para ser utilizado em seus métodos padrões. [NOTE] ==== -De fato, o man:rc.subr[8] também usará o pidfile para ver se o daemon já está em execução antes de iniciá-lo. Esta verificação pode ser ignorada usando o argumento `faststart`. +De fato, o man:rc.subr[8] também usa o pidfile para ver se o daemon já está em execução antes de iniciá-lo. Essa verificação pode ser ignorada usando o argumento `faststart`. ==== -➌ Se o daemon não puder ser executado a menos que existam certos arquivos, apenas liste-os em `required_files`, e man:rc.subr[8] irá verificar se esses arquivos existem antes de iniciar o daemon. Também existem `required_dirs` e `required_vars` para diretórios e variáveis de ambiente, respectivamente. Todos eles são descritos em detalhes em man:rc.subr[8]. +➌ Se o daemon não puder ser executado a menos que certos arquivos existam, basta listá-los em `required_files`, e o man:rc.subr[8] verificará se esses arquivos existem antes de iniciar o daemon. Existem também `required_dirs` e `required_vars` para diretórios e variáveis de ambiente, respectivamente. Todos eles são descritos em detalhes no man:rc.subr[8]. [NOTE] ==== -O método padrão de man:rc.subr[8] pode ser forçado a ignorar as verificações de pré-requisitos usando `forcestart` como o argumento para o script. +O método padrão do man:rc.subr[8] pode ser forçado a pular as verificações de pré-requisito usando `forcestart` como argumento para o script. ==== -➍ Podemos personalizar sinais para enviar para o daemon caso eles sejam diferentes dos mais conhecidos. Em particular, `sig_reload` especifica o sinal que faz o daemon recarregar sua configuração; é `SIGHUP` por padrão. Outro sinal é enviado para parar o processo do daemon; o padrão é `SIGTERM`, mas isso pode ser alterado definindo `sig_stop` apropriadamente. +➍ Podemos personalizar sinais a serem enviados ao daemon caso eles difiram dos sinais conhecidos. Em particular, `sig_reload` especifica o sinal que faz com que o daemon recarregue sua configuração; por padrão, é o SIGHUP. Outro sinal é enviado para interromper o processo do daemon; o padrão é o SIGTERM, mas isso pode ser alterado configurando `sig_stop` adequadamente. [NOTE] ==== -Os nomes dos sinais devem ser especificados para o man:rc.subr[8] sem o prefixo `SIG`, como é mostrado no exemplo. A versão do FreeBSD do man:kill[1] pode reconhecer o prefixo `SIG`, mas as versões de outros tipos de sistema operacional não. +As sinalizações devem ser especificadas para o man:rc.subr[8] sem o prefixo `SIG`, como é mostrado no exemplo. A versão do FreeBSD do man:kill[1] pode reconhecer o prefixo `SIG`, mas as versões de outros sistemas operacionais podem não reconhecer. ==== -➎➏ Realizar tarefas adicionais antes ou depois dos métodos padrão é fácil. Para cada argumento de comando suportado pelo nosso script, podemos definir o argumento `_precmd` e `_postcmd`. Esses comandos no man:sh[1] são invocados antes e depois do respectivo método, como é evidente em seus nomes. +➎➏ Realizar tarefas adicionais antes ou depois dos métodos padrões é fácil. Para cada argumento de comando suportado por nosso script, podemos definir `argument_precmd` e `argument_postcmd`. Esses comandos man:sh[1] são invocados antes e depois do respectivo método, como é evidente pelos seus nomes. [NOTE] ==== -Sobrescrever um método padrão com um `argumento _cmd` personalizado ainda não nos impede de fazer uso do `argumento _precmd` ou `argumento _postcmd` se precisarmos. Em particular, o primeiro é bom para verificar condições personalizadas e sofisticadas que devem ser atendidas antes de executar o comando em si. Usar o `argumento _precmd` junto com o `argumento _cmd` nos permite separar logicamente as verificações da ação. +Sobrescrever um método padrão com um `argument_cmd` personalizado ainda não nos impede de usar `argument_precmd` ou `argument_postcmd` se precisarmos. Em particular, o primeiro é bom para verificar condições personalizadas e sofisticadas que devem ser atendidas antes de executar o próprio comando. Usar `argument_precmd` juntamente com `argument_cmd` nos permite separar logicamente as verificações da ação. -Não se esqueça de que você pode amontoar qualquer expressão válida do man:sh[1] nos métodos, pré e pós-comandos definidos por você. Apenas invocar uma função que faz com que o trabalho real seja um bom estilo na maioria dos casos, mas nunca deixe o estilo limitar sua compreensão do que está acontecendo por trás da cortina. +Não se esqueça de que você pode colocar qualquer expressão válida do man:sh[1] nos métodos, pre e pós comandos que você define. Invocar uma função que realiza o trabalho real é um bom estilo na maioria dos casos, mas nunca deixe o estilo limitar sua compreensão do que está acontecendo nos bastidores. ==== -➐ Se quisermos implementar argumentos customizados, que também podem ser considerados como _comandos_ para o nosso script, precisamos listá-los em `extra_commands` e fornecer métodos para manipulá-los. +➐ Se quisermos implementar argumentos personalizados, que também podem ser considerados como _comandos_ para o nosso script, precisamos listá-los em `extra_commands` e fornecer métodos para lidar com eles. [NOTE] ==== -O comando `reload` é especial. Por um lado, tem um método predefinido em man:rc.subr[8]. Por outro lado, `reload` não é oferecido por padrão. A razão é que nem todos os daemons usam o mesmo mecanismo de recarga e alguns não têm nada para recarregar. Portanto, precisamos solicitar explicitamente que a funcionalidade incorporada seja fornecida. Podemos fazer isso via `extra_commands`. +O comando `reload` é especial. Por um lado, ele possui um método predefinido em man:rc.subr[8]. Por outro lado, `reload` não é oferecido por padrão. A razão é que nem todos os daemons usam o mesmo mecanismo de recarga e alguns não têm nada para recarregar. Portanto, precisamos pedir explicitamente que a funcionalidade integrada seja fornecida. Podemos fazer isso por meio de `extra_commands`. -O que obtemos do método padrão para `reload`? Muitas vezes, os daemons recarregam sua configuração na recepção de um sinal - normalmente, `SIGHUP`. Portanto, o man:rc.subr[8] tenta recarregar o daemon enviando um sinal para ele. O sinal é predefinido para `SIGHUP`, mas pode ser personalizado via `sig_reload`, caso necessário. +O que recebemos do método padrão para `reload`? Muitas vezes, os daemons recarregam sua configuração após receber um sinal - geralmente, SIGHUP. Portanto, o man:rc.subr[8] tenta recarregar o daemon enviando um sinal para ele. O sinal é pré-definido como SIGHUP, mas pode ser personalizado via `sig_reload`, se necessário. ==== -➑⓮ Nosso script suporta dois comandos não padrão, `plugh` e `xyzzy`. Nós os vimos listados em `extra_commands`, e agora é hora de fornecer métodos para eles. O método para `xyzzy` é apenas embutido, enquanto que para `plugh` é implementado como a função `mumbled_plugh`. +➑⓮ O nosso script suporta dois comandos não padrão, `plugh` e `xyzzy`. Nós os vimos listados em `extra_commands`, e agora é hora de fornecer métodos para eles. O método para `xyzzy` é apenas inserido em linha enquanto que para `plugh` é implementado como a função `mumbled_plugh`. -Comandos não padrão não são chamados durante a inicialização ou o desligamento. Geralmente eles são para a conveniência do administrador do sistema. Eles também podem ser usados de outros subsistemas, por exemplo, man:devd[8] se especificado em man:devd.conf[5]. +Comandos não padrão não são invocados durante a inicialização ou desligamento. Geralmente, eles são para a conveniência do administrador do sistema. Eles também podem ser usados em outros subsistemas, por exemplo, o man:devd[8] se especificados em man:devd.conf[5]. -A lista completa de comandos disponíveis pode ser encontrada na linha de uso impressa por man:rc.subr[8] quando o script é invocado sem argumentos. Por exemplo, aqui está a linha de uso do script em estudo: +A lista completa de comandos disponíveis pode ser encontrada na linha de uso impressa pelo man:rc.subr[8] quando o script é invocado sem argumentos. Por exemplo, aqui está a linha de uso do script em estudo: -[source,shell] +[source, shell] .... # /etc/rc.d/mumbled -Uso: /etc/rc.d/mumbled [fast|force|one](start|stop|restart|rcvar|reload|plugh|xyzzy|status|poll) +Usage: /etc/rc.d/mumbled [fast|force|one](start|stop|restart|rcvar|reload|plugh|xyzzy|status|poll) .... -⓭ Um script pode invocar seus próprios comandos padrão ou não padrão, se necessário. Isto pode parecer semelhante as funções de chamada, mas sabemos que comandos e funções de shell nem sempre são a mesma coisa. Por exemplo, `xyzzy` não é implementado como uma função aqui. Além disso, pode haver um pré-comando e um pós-comando, que devem ser chamados ordenadamente. Portanto, a maneira correta de um script executar seu próprio comando é por meio de man:rc.subr[8], conforme mostrado no exemplo. +⓭ Um script pode invocar seus próprios comandos padrão ou não-padrão, se necessário. Isso pode parecer semelhante a chamar funções, mas sabemos que comandos e funções do shell nem sempre são a mesma coisa. Por exemplo, `xyzzy` não é implementado como uma função aqui. Além disso, pode haver um pré-comando e um pós-comando, que devem ser invocados ordenadamente. Portanto, a maneira adequada para um script executar seu próprio comando é por meio do man:rc.subr[8], como mostrado no exemplo. -➒ Uma função útil chamada `checkyesno` é fornecida por man:rc.subr[8]. Ele usa um nome de variável como argumento e retorna um código de saída zero se, e somente se, a variável estiver configurada como `YES`, ou `TRUE`, ou `ON`, ou `1`, sem distinção entre maiúsculas e minúsculas; um código de saída diferente de zero é retornado de outra forma. No último caso, a função testa a variável como sendo definida como `NO`,`FALSE`,`OFF` ou `0` insensível a maiúsculas e minúsculas; imprime uma mensagem de aviso se a variável contiver qualquer outra coisa, ou seja, lixo. +➒ Uma função útil chamada `checkyesno` é fornecida pelo man:rc.subr[8]. Ela recebe um nome de variável como argumento e retorna um código de saída zero se e somente se a variável estiver definida como `YES`, ou `TRUE`, ou `ON`, ou `1`, insensível a maiúsculas e minúsculas; um código de saída não-zero é retornado caso contrário. Neste último caso, a função testa se a variável está definida como `NO`, `FALSE`, `OFF` ou `0`, insensível a maiúsculas e minúsculas; ela imprime uma mensagem de aviso se a variável contiver qualquer outra coisa, ou seja, lixo. -Tenha em mente que para o man:sh[1] um código de saída zero significa verdadeiro e um código de saída diferente de zero significa falso. +Tenha em mente que para o man:sh[1], um código de saída zero significa verdadeiro e um código de saída não-zero significa falso. [IMPORTANT] ==== -A função `checkyesno` recebe um __nome da variável__. Não passe o _valor_ expandido de uma variável para ele; não funcionará como esperado. +A função `checkyesno` recebe um __nome de variável__. Não passe o _valor expandido_ de uma variável para ela; isso não funcionará como esperado. -O uso correto de `checkyesno` é: +Aqui está o uso correto de `checkyesno`: [.programlisting] .... @@ -407,7 +410,7 @@ if checkyesno mumbled_enable; then fi .... -Pelo contrário, chamar `checkyesno` como mostrado abaixo não funcionará - pelo menos não como esperado: +Ao contrário, chamar `checkyesno` como mostrado abaixo não funcionará - pelo menos não como esperado: [.programlisting] .... @@ -418,34 +421,34 @@ fi ==== -➓ [[rc-flags]] Podemos afetar os sinalizadores a serem passados para `$command` modificando `rc_flags` em `$start_precmd`. +➓ [[rc-flags]]Podemos afetar as flags que serão passadas para `$command` modificando `rc_flags` em `$start_precmd`. -⓫ Em certos casos, podemos precisar emitir uma mensagem importante que também deve ser enviada para o `syslog`. Isto pode ser feito facilmente com as seguintes funções man:rc.subr[8]: `debug`, `info`, `warn` e `err`. A última função, em seguida, sai do script com o código especificado. +⓫ Em certos casos, podemos precisar emitir uma mensagem importante que também deve ser registrada no `syslog`. Isso pode ser feito facilmente com as seguintes funções do man:rc.subr[8]: `debug`, `info`, `warn` e `err`. Esta última função finaliza o script com o código especificado. -⓬ Os códigos de saída dos métodos e seus pré-comandos não são apenas ignorados por padrão. Se o argumento `_precmd` retornar um código de saída diferente de zero, o método principal não será executado. Por sua vez, o `argumento_postcmd` não será invocado a menos que o método principal retorne um código de saída zero. +⓬ Os códigos de saída dos métodos e seus pre-comandos não são apenas ignorados por padrão. Se `argument_precmd` retornar um código de saída diferente de zero, o método principal não será executado. Por sua vez, `argument_postcmd` não será chamado, a menos que o método principal retorne um código de saída igual a zero. [NOTE] ==== -No entanto, o man:rc.subr[8] pode ser instruído a partir da linha de comando para ignorar esses códigos de saída e invocar todos os comandos, prefixando um argumento com `force`, como em `forcestart`. +Entretanto, é possível instruir o man:rc.subr[8] a ignorar esses códigos de saída e executar todos os comandos mesmo assim, adicionando um argumento com o prefixo `force`, como em `forcestart`. ==== [[rcng-hookup]] == Conectando um script ao framework rc.d -Depois que um script foi escrito, ele precisa ser integrado em [.filename]#rc.d>#. O passo crucial é instalar o script em [.filename]#/etc/rc.d# (para o sistema base) ou [.filename]#/usr/local/etc/rc.d# (para ports). Ambos [.filename]#bsd.prog.mk# e [.filename]#bsd.port.mk# fornecer ganchos convenientes para isso, e geralmente você não precisa se preocupar com a propriedade e o modo adequado. Os scripts do sistema devem ser instalados a partir do [.filename]#src /etc/rc.d# através do [.filename]#Makefile# encontrado lá. Os scripts de porta podem ser instalados usando `USE_RC_SUBR` conforme descrito em extref:{porters-handbook}[no Manual do Porter, rc-scripts]. +Depois que um script é escrito, ele precisa ser integrado ao [.filename]#rc.d#. O passo crucial é instalar o script em [.filename]#/etc/rc.d# (para o sistema base) ou [.filename]#/usr/local/etc/rc.d# (para o ports). Tanto o [.filename]#bsd.prog.mk# quanto o [.filename]#bsd.port.mk# fornecem ganchos convenientes para isso, e geralmente você não precisa se preocupar com a propriedade e o modo adequados. Os scripts do sistema devem ser instalados a partir de [.filename]#src/libexec/rc/rc.d# através do [.filename]#Makefile# encontrado lá. Scripts de ports podem ser instalados usando `USE_RC_SUBR` como descrito no extref:{porters-handbook}[Porter's Handbook, rc-scripts]. No entanto, devemos considerar antecipadamente o local do nosso script na sequência de inicialização do sistema. O serviço manipulado pelo nosso script provavelmente depende de outros serviços. Por exemplo, um daemon de rede não pode funcionar sem as interfaces de rede e o roteamento em funcionamento. Mesmo que um serviço pareça não exigir nada, dificilmente pode ser iniciado antes que os sistemas de arquivos básicos tenham sido verificados e montados. -Nós já mencionamos o man:rcorder[8]. Agora é hora de dar uma olhada de perto. Em poucas palavras, o man:rcorder[8] pega um conjunto de arquivos, examina seu conteúdo e imprime uma lista ordenada por dependência de arquivos do conjunto para `stdout`. O objetivo é manter as informações de dependência _dentro_ dos arquivos para que cada arquivo possa falar por si só. Um arquivo pode especificar as seguintes informações: +Nós já mencionamos o man:rcorder[8]. Agora é hora de dar uma olhada mais de perto nele. Em poucas palavras, o man:rcorder[8] pega um conjunto de arquivos, examina seus conteúdos e imprime uma lista ordenada por dependência dos arquivos do conjunto no `stdout`. O objetivo é manter as informações de dependência _dentro_ dos arquivos, de modo que cada arquivo possa falar apenas por si mesmo. Um arquivo pode especificar as seguintes informações: -* os nomes das "condições" (o que significa serviços para nós) que ele __fornece__; +* os nomes das "condições" (ou seja, serviços para nós) que ele __fornece__; * os nomes das "condições" que ele __requer__; -* os nomes das "condições" deste arquivo devem ser executados __antes__; -* _palavras-chave adicionais_ que podem ser usadas para selecionar um subconjunto de todo o conjunto de arquivos (man:rcorder[8] podem ser instruídos através de opções para incluir ou omitir os arquivos com determinadas palavras-chave listadas.) +* os nomes das "condições" que este arquivo deve ser executado __antes__; +* palavras-chave adicionais que podem ser usadas para selecionar um subconjunto do conjunto completo de arquivos (man:rcorder[8] pode ser instruído via opções para incluir ou omitir os arquivos que possuem determinadas palavras-chave listadas.) -Não é surpresa que man:rcorder[8] possa manipular apenas arquivos de texto com uma sintaxe próxima a de man:sh[1]. Ou seja, linhas especiais compreendidas por man:rcorder[8] se parecem com comentários man:sh[1]. A sintaxe de tais linhas especiais é bastante rígida para simplificar seu processamento. Veja man:rcorder[8] para detalhes. +Não é surpresa que o man:rcorder[8] possa lidar apenas com arquivos de texto com uma sintaxe próxima à do man:sh[1]. Ou seja, as linhas especiais entendidas pelo man:rcorder[8] se parecem com comentários do man:sh[1]. A sintaxe dessas linhas especiais é bastante rígida para simplificar seu processamento. Consulte man:rcorder[8] para obter detalhes. -Além de usar linhas especiais do man:rcorder[8], um script pode insistir em sua dependência de outro serviço apenas iniciando-o forçadamente. Isso pode ser necessário quando o outro serviço é opcional e não será iniciado automaticamente porque o administrador do sistema o desativou por engano no man:rc.conf[5]. +Além de usar as linhas especiais entendidas pelo man:rcorder[8], um script pode exigir sua dependência de outro serviço simplesmente iniciando-o forçadamente. Isso pode ser necessário quando o outro serviço é opcional e não iniciará por si só porque o administrador do sistema o desativou por engano em man:rc.conf[5]. Com este conhecimento geral em mente, vamos considerar o simples script daemon aprimorado com coisas de dependência: @@ -481,44 +484,55 @@ run_rc_command "$1" Como antes, a análise detalhada segue: -➊ Esta linha declara os nomes das "condições" que nosso script fornece. Agora, outros scripts podem registrar uma dependência em nosso script por estes nomes. +➊ Essa linha declara os nomes das "condições" que nosso script fornece. Agora, outros scripts podem registrar uma dependência em nosso script por esses nomes. [NOTE] ==== Geralmente, um script especifica uma única condição fornecida. No entanto, nada nos impede de listar várias condições, por exemplo, por razões de compatibilidade. -Em qualquer caso, o nome da condição principal, ou a única, `PROVIDE:` deve ser o mesmo que `${name}`. +Em qualquer caso, o nome da condição principal, ou única, `PROVIDE:` deve ser o mesmo que `${name}`. ==== -➋➌ Portanto, nosso script indica quais condições "" são fornecidas por outros scripts dos quais depende. De acordo com as linhas, nosso script pede ao man:rcorder[8] para colocá-lo após o(s) script(s) fornecendo [.filename]#DAEMON# e [.filename]#cleanvar#, mas antes disso prover [.filename]#LOGIN#. +➋➌ Então, nosso script indica em quais "condições" fornecidas por outros scripts ele depende. De acordo com as linhas, nosso script pede para o man:rcorder[8] colocá-lo após o(s) script(s) fornecendo o [.filename]#DAEMON# e o [.filename]#cleanvar#, mas antes daquele que fornece [.filename]#LOGIN#. [NOTE] ==== -A linha `BEFORE:` não deve ser abusada para contornar uma lista de dependências incompleta no outro script. O caso apropriado para usar o `BEFORE:` é quando o outro script não se importa com o nosso, mas nosso script pode fazer sua tarefa melhor se for executado antes do outro. Um típico exemplo da vida real são as interfaces de rede versus o firewall: embora as interfaces não dependam do firewall em realizar seu trabalho, a segurança do sistema se beneficiará do firewall estar pronto antes que haja qualquer tráfego de rede. +A linha `BEFORE:` não deve ser usada para contornar uma lista de dependências incompleta em outro script. O caso apropriado para usar `BEFORE:` é quando o outro script não se importa com o nosso, mas nosso script pode executar sua tarefa melhor se for executado antes do outro. Um exemplo típico da vida real é a relação entre as interfaces de rede e o firewall: embora as interfaces não dependam do firewall para fazer o trabalho delas, a segurança do sistema se beneficiará se o firewall estiver pronto antes de haver qualquer tráfego de rede. -Além das condições correspondentes a um único serviço, existem meta-condições e seus scripts "placeholder" usados para garantir que determinados grupos de operações sejam executados antes dos outros. Estes são denotados pelos nomes [.filename]#UPPERCASE#. Sua lista e finalidades podem ser encontradas em man:rc[8]. +Além das condições correspondentes a um único serviço, existem meta-condições e seus scripts "placeholder" usados para garantir que certos grupos de operações sejam executados antes de outros. Estes são denotados por nomes em [.filename]#UPPERCASE#. Sua lista e propósitos podem ser encontrados no manual man:rc[8]. -Tenha em mente que colocar um nome de serviço na linha `REQUIRE:` não garante que o serviço estará realmente em execução no momento em que nosso script for iniciado. O serviço necessário pode falhar ao iniciar ou simplesmente ser desativado em man:rc.conf[5]. Obviamente, o man:rcorder[8] não pode controlar tais detalhes, e o man:rc[8] também não fará isso. Consequentemente, o aplicativo iniciado por nosso script deve ser capaz de lidar com quaisquer serviços necessários indisponíveis. Em certos casos, podemos ajudá-lo conforme discutido <> +Lembre-se de que colocar o nome de um serviço na linha `REQUIRE:` não garante que o serviço realmente estará em execução no momento em que o script começar. O serviço necessário pode falhar ao iniciar ou simplesmente ser desativado em man:rc.conf[5]. Obviamente, o man:rcorder[8] não pode controlar esses detalhes e o man:rc[8] também não fará isso. Consequentemente, a aplicação iniciada pelo nosso script deve ser capaz de lidar com qualquer serviço necessário que esteja indisponível. Em certos casos, podemos ajudá-lo conforme discutido <> ==== -➍ [[keywords]] Como lembramos do texto acima, as palavras-chave do man:rcorder[8] podem ser usadas para selecionar ou deixar alguns scripts. Ou seja, qualquer consumidor man:rcorder[8] pode especificar através das opções `-k` e `-s` que as palavras-chave estão na "keep list" e na "skip list", respectivamente. De todos os arquivos a serem classificados, o man:rcorder[8] selecionará apenas aqueles que tiverem uma palavra-chave da lista de manutenção (a menos que vazia) e não uma palavra-chave da lista de itens ignorados. +[[keywords]]➍ Como lembramos do texto acima, as palavras-chave do man:rcorder[8] podem ser usadas para selecionar ou deixar de fora alguns scripts. Qualquer consumidor do man:rcorder[8] pode especificar, através das opções `-k` e `-s`, quais palavras-chave estarão na "lista de manutenção" e na "lista de exclusão", respectivamente. De todos os arquivos a serem ordenados por dependência, man:rcorder[8] escolherá apenas aqueles que tiverem uma palavra-chave da lista de manutenção (a menos que esteja vazia) e que não tiverem uma palavra-chave da lista de exclusão. -No FreeBSD, o man:rcorder[8] é usado por [.filename]#/etc/rc# e [.filename]#/etc/rc.shutdown#. Esses dois scripts definem a lista padrão de palavras-chave do [.filename]#rc.d# do FreeBSD e seus significados da seguinte forma: +No FreeBSD, o man:rcorder[8] é usado por [.filename]#/etc/rc# e [.filename]#/etc/rc.shutdown#. Esses dois scripts definem a lista padrão de palavras-chaves do FreeBSD [.filename]#rc.d# e seus significados da seguinte forma: -➎ [[forcedep]] Para começar, `force_depend` deve ser usado com muito cuidado. Geralmente é melhor revisar a hierarquia de variáveis de configuração para seus scripts [.filename]#rc.# se eles forem interdependentes. +nojail:: O serviço não é para ambiente man:jail[8]. Os procedimentos automáticos de inicialização e desligamento ignorarão o script se estiver dentro de uma jail. -Se você ainda não pode fazer sem `force_depend`, o exemplo oferece uma expressão de como invocá-lo condicionalmente. No exemplo, nosso daemon `mumbled` requer que outro, `frotz`, seja iniciado antecipadamente. No entanto, `frotz` é opcional também; e man:rcorder[8] não sabe nada sobre esses detalhes. Felizmente, nosso script tem acesso a todas as variáveis man:rc.conf[5]. Se `frotz_enable` estiver como true, esperamos pelo melhor e dependemos de [.filename]#rc.d# para iniciar `frotz`. Caso contrário, nós forçadamente verificaremos o status de `frotz`. Finalmente, impomos nossa dependência ao `frotz` se ele não estiver sendo executado. Uma mensagem de aviso será emitida por `force_depend` porque ele deve ser chamado apenas se um erro de configuração for detectado. +nostart:: O serviço deve ser iniciado manualmente ou não iniciado de forma alguma. O procedimento de inicialização automático ignorará o script. Em conjunto com a palavra-chave [.filename]#shutdown#, isso pode ser usado para escrever scripts que fazem algo apenas no desligamento do sistema. + +shutdown:: Este palavra-chave deve ser listada de forma __explícita__ se o serviço precisa ser parado antes do desligamento do sistema. + +[NOTE] +==== +Quando o sistema está prestes a desligar, o arquivo [.filename]#/etc/rc.shutdown# é executado. Ele assume que a maioria dos scripts [.filename]#rc.d# não tem nada a fazer nesse momento. Portanto, o [.filename]#/etc/rc.shutdown# invoca seletivamente scripts [.filename]#rc.d# com a palavra-chave [.filename]#shutdown#, ignorando efetivamente o restante dos scripts. Para desligamento ainda mais rápido, o [.filename]#/etc/rc.shutdown# passa o comando [.filename]#faststop# para os scripts que executa para que eles pulem verificações preliminares, como a verificação do pidfile. Como os serviços dependentes devem ser interrompidos antes de suas dependências, o [.filename]#/etc/rc.shutdown# executa os scripts em ordem de dependência reversa. Se você está escrevendo um script [.filename]#rc.d# real, deve considerar se ele é relevante no momento do desligamento do sistema. Por exemplo, se o seu script faz seu trabalho apenas em resposta ao comando [.filename]#start#, então você não precisa incluir essa palavra-chave. No entanto, se o seu script gerencia um serviço, é provavelmente uma boa ideia pará-lo antes que o sistema prossiga para o estágio final de sua sequência de desligamento descrita em man:halt[8]. Em particular, um serviço deve ser interrompido explicitamente se precisar de tempo considerável ou ações especiais para ser desligado corretamente. Um exemplo típico desse tipo de serviço é um mecanismo de banco de dados. +==== + +[[forcedep]] ➎ Em primeiro lugar, `force_depend` deve ser usado com muito cuidado. Geralmente, é melhor revisar a hierarquia das variáveis de configuração para seus scripts [.filename]#rc.d# se eles são interdependentes. + +Se ainda assim você não puder abrir mão do `force_depend`, o exemplo oferece um exemplo de como invocá-lo condicionalmente. No exemplo, nosso daemon `mumbled` requer que outro daemon, `frotz`, seja iniciado antecipadamente. No entanto, `frotz` também é opcional; e o man:rcorder[8] não conhece esses detalhes. Felizmente, nosso script tem acesso a todas as variáveis de man:rc.conf[5]. Se `frotz_enable` for verdadeiro, esperamos o melhor e confiamos no [.filename]#rc.d# para ter iniciado `frotz`. Caso contrário, verificamos forçadamente o status de `frotz`. Finalmente, impomos nossa dependência em `frotz` se ele não estiver em execução. Uma mensagem de aviso será emitida por `force_depend`, pois ele só deve ser invocado se uma configuração incorreta for detectada. [[rcng-args]] == Dando mais flexibilidade a um script rc.d -Quando chamado durante a inicialização ou desligamento, um script [.filename]#rc.d# deve agir em todo o subsistema pelo qual é responsável. Por exemplo, [.filename]#/etc/rc.d/netif# deve iniciar ou parar todas as interfaces de rede descritas por man:rc.conf[5]. Qualquer tarefa pode ser indicada exclusivamente por um único argumento de comando, como `start` ou `stop`. Entre a inicialização e o desligamento, os scripts [.filename]#rc.d# ajudam o administrador a controlar o sistema em execução, e é quando surge a necessidade de mais flexibilidade e precisão. Por exemplo, o administrador pode querer adicionar as configurações de uma nova interface de rede ao man:rc.conf[5] e então iniciá-lo sem interferir o funcionamento das interfaces existentes. Da próxima vez, o administrador pode precisar desligar uma única interface de rede. No espírito da linha de comando, o respectivo script [.filename]#rc.d# solicita um argumento extra, o nome da interface. +Quando invocado durante a inicialização ou desligamento, um script [.filename]#rc.d# deve agir em todo o subsistema pelo qual é responsável. Por exemplo, o [.filename]#/etc/rc.d/netif# deve iniciar ou parar todas as interfaces de rede descritas em man:rc.conf[5]. Cada tarefa pode ser indicada por um único argumento de comando, como `start` ou `stop`. Entre a inicialização e o desligamento, os scripts [.filename]#rc.d# ajudam o administrador a controlar o sistema em execução e é quando surge a necessidade de mais flexibilidade e precisão. Por exemplo, o administrador pode querer adicionar as configurações de uma nova interface de rede em man:rc.conf[5] e, em seguida, iniciá-la sem interferir na operação das interfaces existentes. Na próxima vez, o administrador pode precisar desligar uma única interface de rede. Para facilitar o uso na linha de comando, o respectivo script [.filename]#rc.d# pede um argumento extra, o nome da interface. -Felizmente, man:rc.subr[8] permite passar qualquer número de argumentos para os métodos do script (dentro dos limites do sistema). Devido a isso, as alterações no próprio script podem ser mínimas. +Felizmente, o man:rc.subr[8] permite passar qualquer número de argumentos para os métodos do script (dentro dos limites do sistema). Devido a isso, as mudanças no próprio script podem ser mínimas. -Como o man:rc.subr[8] pode obter acesso aos argumentos de linha de comando extra. Deveria pegá-los diretamente? Não por qualquer meio. Primeiro, uma função man:sh[1] não tem acesso aos parâmetros posicionais de seu chamador, mas o man:rc.subr[8] é apenas uma despedida de tais funções. Em segundo lugar, a boa maneira de [.filename]#rc.d# determina que é para o script principal decidir quais argumentos devem ser passados para seus métodos. +Como o man:rc.subr[8] pode ter acesso aos argumentos adicionais da linha de comando? Ele deve simplesmente pegá-los diretamente? De maneira alguma! Em primeiro lugar, uma função do man:sh[1] não tem acesso aos parâmetros posicionais de quem a chamou, mas o man:rc.subr[8] é apenas um conjunto dessas funções. Em segundo lugar, a boa prática do [.filename]#rc.d# dita que é responsabilidade do script principal decidir quais argumentos devem ser passados para seus métodos. -Portanto, a abordagem adotada por man:rc.subr[8] é a seguinte: `run_rc_command` transmite todos os seus argumentos, mas o primeiro um para o respectivo método na íntegra. O primeiro, omitido, argumento é o nome do próprio método: `start`,`stop`, etc. Ele será deslocado por `run_rc_command`, então o que é `$2` na linha de comando original será apresentado como `$1` ao método, e assim por diante. +Portanto, a abordagem adotada pelo man:rc.subr[8] é a seguinte: `run_rc_command` passa todos os seus argumentos, exceto o primeiro, ao respectivo método sem alterações. O primeiro argumento omitido é o nome do método em si: `start`, `stop`, etc. Ele será removido por `run_rc_command`, então o que é `$2` na linha de comando original será apresentado como `$1` para o método, e assim por diante. Para ilustrar essa oportunidade, vamos modificar o script fictício primitivo para que suas mensagens dependam dos argumentos adicionais fornecidos. Aqui vamos nós: @@ -565,43 +579,45 @@ run_rc_command "$@" <.> Quais mudanças essenciais podemos notar no script? -➊ Todos os argumentos digitados após `start` podem terminar como parâmetros posicionais para o respectivo método. Podemos usá-los de qualquer maneira de acordo com nossa tarefa, habilidades e fantasia. No exemplo atual, apenas passamos todos eles para man:echo[1] como uma cadeia na linha seguinte - note `$*` entre aspas duplas. Aqui está como o script pode ser chamado agora: +➊ Todos os argumentos que você digita após `start` podem acabar como parâmetros posicionais para o respectivo método. Podemos usá-los de qualquer maneira de acordo com nossa tarefa, habilidades e gosto. No exemplo atual, simplesmente passamos todos eles para o man:echo[1] como uma única string na próxima linha - observe o `$*` dentro das aspas duplas. Aqui está como o script pode ser invocado agora: -[source,shell] +[source, shell] .... # /etc/rc.d/dummy start Nothing started. + # /etc/rc.d/dummy start Hello world! Greeting message: Hello world! .... -➋ O mesmo se aplica a qualquer método que nosso script forneça, não apenas a um método padrão. Nós adicionamos um método customizado chamado `kiss`, e ele pode tirar proveito dos argumentos extras da mesma forma que o `start` tira. Por exemplo: +➋ O mesmo se aplica a qualquer método que nosso script ofereça, não apenas a um padrão. Adicionamos um método personalizado chamado `kiss`, e ele pode tirar proveito dos argumentos extras da mesma forma que o `start` pode. Por exemplo: -[source,shell] +[source, shell] .... # /etc/rc.d/dummy kiss A ghost gives you a kiss. + # /etc/rc.d/dummy kiss Once I was Etaoin Shrdlu... A ghost gives you a kiss and whispers: Once I was Etaoin Shrdlu... .... -➌ Se quisermos apenas passar todos os argumentos extras para qualquer método, podemos simplesmente substituir `"$@"` por `"$ 1"` na última linha do nosso script, onde invocamos o `run_rc_command`. +➌ Se quisermos apenas passar todos os argumentos extras para qualquer método, podemos simplesmente substituir `"$1"` por `"$@"` na última linha do nosso script, onde invocamos `run_rc_command`. [IMPORTANT] ==== -Um programador man:sh[1] deve entender a diferença sutil entre `$*` e `$@` como as formas de designar todos os parâmetros posicionais. Para sua discussão aprofundada, consulte um bom manual sobre programação de scripts man:sh[1]. _Não_ use estas expressões até que você as compreenda completamente, porque o uso incorreto delas resultará em scripts inseguros e contendo bugs. +Um programador em man:sh[1] deve entender a diferença sutil entre `$*` e `$@` como formas de designar todos os parâmetros posicionais. Para uma discussão aprofundada, consulte um bom manual de man:sh[1]. Não use essas expressões até entender completamente o seu uso, pois o uso incorreto pode resultar em scripts com bugs e inseguros. ==== [NOTE] ==== -Atualmente, o `run_rc_command` pode ter um bug que o impede de manter os limites originais entre os argumentos. Ou seja, argumentos com espaços em branco incorporados podem não ser processados corretamente. O bug deriva do uso inadequado de `$*`. +Atualmente, o `run_rc_command` pode ter um bug que o impede de manter as fronteiras originais entre os argumentos. Ou seja, argumentos com espaços em branco embutidos podem não ser processados corretamente. O bug decorre do uso inadequado de `$*`. ==== [[rcng-furthur]] == Leitura adicional -[[lukem]]http://www.mewburn.net/luke/papers/rc.d.pdf[O artigo original de Luke Mewburn] oferece uma visão geral do [.filename]#rc.d# e o raciocínio detalhado que o levou a suas decisões de design. Ele fornece informações sobre toda o framework do [.filename]#rc.d# e o seu lugar em um moderno sistema operacional BSD. +[[lukem]]http://www.mewburn.net/luke/papers/rc.d.pdf[O artigo original de Luke Mewburn] oferece uma visão geral do [.filename]#rc.d# e uma justificativa detalhada para suas decisões de design. Ele fornece uma compreensão do quadro geral do [.filename]#rc.d# e seu lugar em um sistema operacional BSD moderno. -[[manpages]]As páginas de manual man:rc[8], man:rc.subr[8] e man:rcorder[8] documentam os componentes do [.filename]#rc.d# com grande detalhe. Você não pode usar totalmente o poder do [.filename]#rc.d# sem estudar as páginas de manual e se referir a elas enquanto escreve seus próprios scripts. +[[manpages]]As páginas do manual para man:rc[8], man:rc.subr[8] e man:rcorder[8] documentam em detalhes os componentes do sistema [.filename]#rc.d#. Você não pode aproveitar completamente o poder do [.filename]#rc.d# sem estudar as páginas do manual e consultá-las ao escrever seus próprios scripts. -A sua principal fonte de inspiração são os exemplos da vida real, existentes em no [.filename]#/etc/rc.d# de um sistema vivo. Seu conteúdo é fácil e agradável de ler, porque a maioria dos cantos ásperos estão escondidos fundo no man:rc.subr[8]. Tenha em mente que os scripts [.filename]#/etc/rc.d# não foram escritos por anjos, então eles podem sofrer de bugs e decisões sub-ótimas de design. Agora você pode melhorá-los! +A principal fonte de exemplos práticos e funcionais é o diretório [.filename]#/etc/rc.d# em um sistema em operação. O seu conteúdo é fácil e agradável de ler, pois a maioria das partes difíceis está escondida profundamente em man:rc.subr[8]. No entanto, tenha em mente que os scripts em [.filename]#/etc/rc.d# não foram escritos por anjos, então eles podem conter bugs e decisões de design subótimas. Agora você pode melhorá-los! diff --git a/documentation/content/pt-br/articles/rc-scripting/_index.po b/documentation/content/pt-br/articles/rc-scripting/_index.po new file mode 100644 index 0000000000..eaee8ffb75 --- /dev/null +++ b/documentation/content/pt-br/articles/rc-scripting/_index.po @@ -0,0 +1,2337 @@ +# SOME DESCRIPTIVE TITLE +# Copyright (C) YEAR The FreeBSD Project +# This file is distributed under the same license as the FreeBSD Documentation package. +# Danilo G. Baio , 2021, 2022. +# Edson Brandi , 2023. +# "Danilo G. Baio" , 2023. +msgid "" +msgstr "" +"Project-Id-Version: FreeBSD Documentation VERSION\n" +"POT-Creation-Date: 2022-07-07 23:23-0300\n" +"PO-Revision-Date: 2023-04-30 08:49+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" +"Plural-Forms: nplurals=2; plural=n > 1;\n" +"X-Generator: Weblate 4.17\n" + +#. type: YAML Front Matter: description +#: documentation/content/en/articles/rc-scripting/_index.adoc:1 +#, no-wrap +msgid "A guide to writing new rc.d scripts and understanding those already written" +msgstr "" +"Um guia para escrever novos scripts rc.d e entender aqueles que já existem" + +#. type: Title = +#: documentation/content/en/articles/rc-scripting/_index.adoc:1 +#: documentation/content/en/articles/rc-scripting/_index.adoc:12 +#, no-wrap +msgid "Practical rc.d scripting in BSD" +msgstr "Scripting rc.d na prática no BSD" + +#. type: Plain text +#: documentation/content/en/articles/rc-scripting/_index.adoc:45 +msgid "Abstract" +msgstr "Resumo" + +#. type: Plain text +#: documentation/content/en/articles/rc-scripting/_index.adoc:49 +msgid "" +"Beginners may find it difficult to relate the facts from the formal " +"documentation on the BSD [.filename]#rc.d# framework with the practical " +"tasks of [.filename]#rc.d# scripting. In this article, we consider a few " +"typical cases of increasing complexity, show [.filename]#rc.d# features " +"suited for each case, and discuss how they work. Such an examination should " +"provide reference points for further study of the design and efficient " +"application of [.filename]#rc.d#." +msgstr "" +"Os iniciantes podem achar difícil relacionar os fatos da documentação formal " +"sobre o framework [.filename]#rc.d# do BSD com as tarefas práticas de " +"escrever scripts [.filename]#rc.d#. Neste artigo, consideramos alguns casos " +"típicos de crescente complexidade, mostramos recursos do [.filename]#rc.d# " +"adequados para cada caso e discutimos como eles funcionam. Essa análise deve " +"fornecer pontos de referência para estudos posteriores do design e aplicação " +"eficiente do [.filename]#rc.d#." + +#. type: Plain text +#: documentation/content/en/articles/rc-scripting/_index.adoc:51 +msgid "'''" +msgstr "'''" + +#. type: Title == +#: documentation/content/en/articles/rc-scripting/_index.adoc:55 +#, no-wrap +msgid "Introduction" +msgstr "Introdução" + +#. type: Plain text +#: documentation/content/en/articles/rc-scripting/_index.adoc:61 +msgid "" +"The historical BSD had a monolithic startup script, [.filename]#/etc/rc#. " +"It was invoked by man:init[8] at system boot time and performed all userland " +"tasks required for multi-user operation: checking and mounting file systems, " +"setting up the network, starting daemons, and so on. The precise list of " +"tasks was not the same in every system; admins needed to customize it. With " +"few exceptions, [.filename]#/etc/rc# had to be modified, and true hackers " +"liked it." +msgstr "" +"No histórico BSD, havia um script de inicialização monolítico, [.filename]#/" +"etc/rc#. Ele era invocado pelo man:init[8] no momento da inicialização do " +"sistema e realizava todas as tarefas de usuário necessárias para a operação " +"multiusuário: verificação e montagem de sistemas de arquivos, configuração " +"da rede, inicialização de daemons e assim por diante. A lista precisa de " +"tarefas não era a mesma em todos os sistemas; os administradores precisavam " +"personalizá-la. Com poucas exceções, o [.filename]#/etc/rc# tinha que ser " +"modificado, e os verdadeiros hackers gostavam disso." + +#. type: Plain text +#: documentation/content/en/articles/rc-scripting/_index.adoc:67 +msgid "" +"The real problem with the monolithic approach was that it provided no " +"control over the individual components started from [.filename]#/etc/rc#. " +"For instance, [.filename]#/etc/rc# could not restart a single daemon. The " +"system admin had to find the daemon process by hand, kill it, wait until it " +"actually exited, then browse through [.filename]#/etc/rc# for the flags, and " +"finally type the full command line to start the daemon again. The task " +"would become even more difficult and prone to errors if the service to " +"restart consisted of more than one daemon or demanded additional actions. " +"In a few words, the single script failed to fulfil what scripts are for: to " +"make the system admin's life easier." +msgstr "" +"O problema real com a abordagem monolítica era que ela não fornecia controle " +"sobre os componentes individuais iniciados a partir do [.filename]#/etc/rc#. " +"Por exemplo, o [.filename]#/etc/rc# não podia reiniciar um único daemon. O " +"administrador do sistema tinha que encontrar o processo do daemon " +"manualmente, matá-lo, aguardar até que ele realmente finalizasse, navegar " +"por [.filename]#/etc/rc# em busca das flags e, finalmente, digitar a linha " +"de comando completa para iniciar o daemon novamente. A tarefa se tornaria " +"ainda mais difícil e propensa a erros se o serviço a ser reiniciado " +"consistisse em mais de um daemon ou exigisse ações adicionais. Em poucas " +"palavras, o script único falhou em cumprir o objetivo pelo qual um script é " +"criado: tornar a vida do administrador do sistema mais fácil." + +#. type: Plain text +#: documentation/content/en/articles/rc-scripting/_index.adoc:74 +msgid "" +"Later there was an attempt to split out some parts of [.filename]#/etc/rc# " +"for the sake of starting the most important subsystems separately. The " +"notorious example was [.filename]#/etc/netstart# to bring up networking. It " +"did allow for accessing the network from single-user mode, but it did not " +"integrate well into the automatic startup process because parts of its code " +"needed to interleave with actions essentially unrelated to networking. That " +"was why [.filename]#/etc/netstart# mutated into [.filename]#/etc/rc." +"network#. The latter was no longer an ordinary script; it comprised of " +"large, tangled man:sh[1] functions called from [.filename]#/etc/rc# at " +"different stages of system startup. However, as the startup tasks grew " +"diverse and sophisticated, the \"quasi-modular\" approach became even more " +"of a drag than the monolithic [.filename]#/etc/rc# had been." +msgstr "" +"Mais tarde, houve uma tentativa de dividir algumas partes do [.filename]#/" +"etc/rc# para iniciar os subsistemas mais importantes separadamente. O " +"exemplo notório foi o [.filename]#/etc/netstart# para iniciar a rede. Isso " +"permitiu o acesso à rede no modo de usuário único, mas não se integrou bem " +"ao processo de inicialização automática porque partes de seu código " +"precisavam intercalar com ações essencialmente não relacionadas à rede. Foi " +"por isso que o [.filename]#/etc/netstart# se transformou em [.filename]#/etc/" +"rc.network#. Este último não era mais um script comum; era composto de " +"grandes funções man:sh[1] complexas chamadas pelo [.filename]#/etc/rc# em " +"diferentes estágios da inicialização do sistema. No entanto, à medida que as " +"tarefas de inicialização ficaram mais diversas e sofisticadas, a abordagem " +"\"quase modular\" tornou-se ainda mais pesada do que o monolítico [." +"filename]#/etc/rc# tinha sido." + +#. type: Plain text +#: documentation/content/en/articles/rc-scripting/_index.adoc:82 +msgid "" +"Without a clean and well-designed framework, the startup scripts had to bend " +"over backwards to satisfy the needs of rapidly developing BSD-based " +"operating systems. It became obvious at last that more steps are necessary " +"on the way to a fine-grained and extensible [.filename]#rc# system. Thus " +"BSD [.filename]#rc.d# was born. Its acknowledged fathers were Luke Mewburn " +"and the NetBSD community. Later it was imported into FreeBSD. Its name " +"refers to the location of system scripts for individual services, which is " +"in [.filename]#/etc/rc.d#. Soon we will learn about more components of the " +"[.filename]#rc.d# system and see how the individual scripts are invoked." +msgstr "" +"Sem um framework limpo e bem projetado, os scripts de inicialização tiveram " +"que se dobrar para atender às necessidades dos sistemas operacionais " +"baseados em BSD que estavam em rápida evolução. Tornou-se evidente, " +"finalmente, que mais etapas eram necessárias para se chegar a um sistema [." +"filename]#rc# refinado, granular e extensível. Assim nasceu o [.filename]#rc." +"d# do BSD. Seus pais reconhecidos foram Luke Mewburn e a comunidade NetBSD. " +"Mais tarde, foi importado para o FreeBSD. Seu nome se refere ao local dos " +"scripts do sistema para serviços individuais, que está em [.filename]#/etc/rc" +".d#. Em breve, aprenderemos mais sobre os componentes do sistema [." +"filename]#rc.d# e veremos como os scripts individuais são invocados." + +#. type: Plain text +#: documentation/content/en/articles/rc-scripting/_index.adoc:93 +msgid "" +"The basic ideas behind BSD [.filename]#rc.d# are _fine modularity_ and " +"__code reuse__. _Fine modularity_ means that each basic \"service\" such as " +"a system daemon or primitive startup task gets its own man:sh[1] script able " +"to start the service, stop it, reload it, check its status. A particular " +"action is chosen by the command-line argument to the script. The [." +"filename]#/etc/rc# script still drives system startup, but now it merely " +"invokes the smaller scripts one by one with the `start` argument. It is " +"easy to perform shutdown tasks as well by running the same set of scripts " +"with the `stop` argument, which is done by [.filename]#/etc/rc.shutdown#. " +"Note how closely this follows the Unix way of having a set of small " +"specialized tools, each fulfilling its task as well as possible. _Code " +"reuse_ means that common operations are implemented as man:sh[1] functions " +"and collected in [.filename]#/etc/rc.subr#. Now a typical script can be " +"just a few lines' worth of man:sh[1] code. Finally, an important part of " +"the [.filename]#rc.d# framework is man:rcorder[8], which helps [.filename]#/" +"etc/rc# to run the small scripts orderly with respect to dependencies " +"between them. It can help [.filename]#/etc/rc.shutdown#, too, because the " +"proper order for the shutdown sequence is opposite to that of startup." +msgstr "" +"As ideias básicas por trás do [.filename]#rc.d# do BSD são _modularidade " +"fina_ e __reutilização de código__. _Modularidade fina_ significa que cada " +"\"serviço\" básico, como um daemon do sistema ou uma tarefa de inicialização " +"primitiva, possui seu próprio script man:sh[1] capaz de iniciar o serviço, " +"pará-lo, recarregá-lo e verificar seu status. Uma ação específica é " +"escolhida pelo argumento da linha de comando do script. O script [." +"filename]#/etc/rc# ainda conduz a inicialização do sistema, mas agora ele " +"apenas invoca os scripts menores um por um com o argumento `start`. Também é " +"fácil realizar tarefas de desligamento executando o mesmo conjunto de " +"scripts com o argumento `stop`, que é feito por [.filename]#/etc/rc.shutdown#" +". Observe como isso segue de perto a maneira Unix de ter um conjunto de " +"ferramentas especializadas pequenas, cada uma cumprindo sua tarefa da melhor " +"maneira possível. _Reutilização de código_ significa que operações comuns " +"são implementadas como funções man:sh[1] e coletadas em [.filename]#/etc/rc." +"subr#. Agora, um script típico pode ser composto apenas de algumas linhas de " +"código man:sh[1]. Finalmente, uma parte importante do framework [." +"filename]#rc.d# é o man:rcorder[8], que ajuda o [.filename]#/etc/rc# a " +"executar os pequenos scripts de maneira ordenada com respeito às " +"dependências entre eles. Isso também pode ajudar o [.filename]#/etc/rc." +"shutdown#, porque a ordem apropriada para a sequência de desligamento é " +"oposta à de inicialização." + +#. type: Plain text +#: documentation/content/en/articles/rc-scripting/_index.adoc:101 +msgid "" +"The BSD [.filename]#rc.d# design is described in <>, and the [.filename]#rc.d# components are " +"documented in great detail in <>. " +"However, it might not appear obvious to an [.filename]#rc.d# newbie how to " +"tie the numerous bits and pieces together in order to create a well-styled " +"script for a particular task. Therefore this article will try a different " +"approach to describe [.filename]#rc.d#. It will show which features should " +"be used in a number of typical cases, and why. Note that this is not a how-" +"to document because our aim is not at giving ready-made recipes, but at " +"showing a few easy entrances into the [.filename]#rc.d# realm. Neither is " +"this article a replacement for the relevant manual pages. Do not hesitate " +"to refer to them for more formal and complete documentation while reading " +"this article." +msgstr "" +"O design do BSD [.filename]#rc.d# é descrito no <>, e os componentes do [.filename]#rc.d# são documentados em " +"grande detalhe nas <>. No entanto, " +"pode não ser óbvio para um iniciante no [.filename]#rc.d# como ele deve unir " +"as numerosas partes para criar um script bem estruturado para uma tarefa " +"específica. Portanto, este artigo tentará abordar o [.filename]#rc.d# de " +"forma diferente. Mostrará quais recursos devem ser usados em vários casos " +"típicos e por que. Observe que este não é um documento de \"como fazer\", " +"porque nosso objetivo não é fornecer receitas prontas, mas mostrar algumas " +"entradas fáceis no mundo do [.filename]#rc.d#. Este artigo também não " +"substitui as páginas do manual relevantes. Não hesite em consultá-las para " +"obter documentação mais formal e completa enquanto lê este artigo." + +#. type: Plain text +#: documentation/content/en/articles/rc-scripting/_index.adoc:105 +msgid "" +"There are prerequisites to understanding this article. First of all, you " +"should be familiar with the man:sh[1] scripting language in order to master " +"[.filename]#rc.d#. In addition, you should know how the system performs " +"userland startup and shutdown tasks, which is described in man:rc[8]." +msgstr "" +"Existem pré-requisitos para entender este artigo. Em primeiro lugar, você " +"deve estar familiarizado com a linguagem de script man:sh[1] para dominar o [" +".filename]#rc.d#. Além disso, você deve saber como o sistema realiza tarefas " +"de inicialização e desligamento do espaço do usuário, o que é descrito em " +"man:rc[8]." + +#. type: Plain text +#: documentation/content/en/articles/rc-scripting/_index.adoc:108 +msgid "" +"This article focuses on the FreeBSD branch of [.filename]#rc.d#. " +"Nevertheless, it may be useful to NetBSD developers, too, because the two " +"branches of BSD [.filename]#rc.d# not only share the same design but also " +"stay similar in their aspects visible to script authors." +msgstr "" +"Este artigo foca no ramo do FreeBSD do [.filename]#rc.d#. No entanto, ele " +"pode ser útil também para desenvolvedores do NetBSD, pois os dois ramos do [." +"filename]#rc.d# não apenas compartilham o mesmo design, mas também " +"permanecem similares em seus aspectos visíveis aos autores de scripts." + +#. type: Title == +#: documentation/content/en/articles/rc-scripting/_index.adoc:110 +#, no-wrap +msgid "Outlining the task" +msgstr "Esboçando a tarefa" + +#. type: Plain text +#: documentation/content/en/articles/rc-scripting/_index.adoc:114 +msgid "" +"A little consideration before starting `$EDITOR` will not hurt. In order to " +"write a well-tempered [.filename]#rc.d# script for a system service, we " +"should be able to answer the following questions first:" +msgstr "" +"Uma pequena reflexão antes de iniciar o `$EDITOR` não fará mal. Para " +"escrever um script [.filename]#rc.d# bem elaborado para um serviço do " +"sistema, devemos ser capazes de responder às seguintes perguntas primeiro:" + +#. type: Plain text +#: documentation/content/en/articles/rc-scripting/_index.adoc:116 +msgid "Is the service mandatory or optional?" +msgstr "O serviço é obrigatório ou opcional?" + +#. type: Plain text +#: documentation/content/en/articles/rc-scripting/_index.adoc:117 +msgid "" +"Will the script serve a single program, e.g., a daemon, or perform more " +"complex actions?" +msgstr "" +"O script servirá um único programa, por exemplo, um daemon, ou realizará " +"ações mais complexas?" + +#. type: Plain text +#: documentation/content/en/articles/rc-scripting/_index.adoc:118 +msgid "Which other services will our service depend on, and vice versa?" +msgstr "De quais outros serviços nosso serviço dependerá e vice-versa?" + +#. type: Plain text +#: documentation/content/en/articles/rc-scripting/_index.adoc:120 +msgid "" +"From the examples that follow we will see why it is important to know the " +"answers to these questions." +msgstr "" +"A partir dos exemplos que se seguem, veremos o porque é importante conhecer " +"as respostas a essas perguntas." + +#. type: Title == +#: documentation/content/en/articles/rc-scripting/_index.adoc:122 +#, no-wrap +msgid "A dummy script" +msgstr "Um script fictício" + +#. type: Plain text +#: documentation/content/en/articles/rc-scripting/_index.adoc:125 +msgid "" +"The following script just emits a message each time the system boots up:" +msgstr "" +"O script a seguir apenas emite uma mensagem toda vez que o sistema é " +"inicializado:" + +#. type: delimited block . 4 +#: documentation/content/en/articles/rc-scripting/_index.adoc:129 +#, no-wrap +msgid "#!/bin/sh <.>\n" +msgstr "#!/bin/sh <.>\n" + +#. type: delimited block . 4 +#: documentation/content/en/articles/rc-scripting/_index.adoc:131 +#, no-wrap +msgid ". /etc/rc.subr <.>\n" +msgstr ". /etc/rc.subr <.>\n" + +#. type: delimited block . 4 +#: documentation/content/en/articles/rc-scripting/_index.adoc:135 +#, no-wrap +msgid "" +"name=\"dummy\" <.>\n" +"start_cmd=\"${name}_start\" <.>\n" +"stop_cmd=\":\" <.>\n" +msgstr "" +"name=\"dummy\" <.>\n" +"start_cmd=\"${name}_start\" <.>\n" +"stop_cmd=\":\" <.>\n" + +#. type: delimited block . 4 +#: documentation/content/en/articles/rc-scripting/_index.adoc:140 +#, no-wrap +msgid "" +"dummy_start() <.>\n" +"{\n" +"\techo \"Nothing started.\"\n" +"}\n" +msgstr "" +"dummy_start() <.>\n" +"{\n" +"\techo \"Nothing started.\"\n" +"}\n" + +#. type: delimited block . 4 +#: documentation/content/en/articles/rc-scripting/_index.adoc:143 +#, no-wrap +msgid "" +"load_rc_config $name <.>\n" +"run_rc_command \"$1\" <.>\n" +msgstr "" +"load_rc_config $name <.>\n" +"run_rc_command \"$1\" <.>\n" + +#. type: Plain text +#: documentation/content/en/articles/rc-scripting/_index.adoc:146 +msgid "Things to note are:" +msgstr "Os pontos a serem observados são:" + +#. type: Plain text +#: documentation/content/en/articles/rc-scripting/_index.adoc:152 +msgid "" +"➊ An interpreted script should begin with the magic \"shebang\" " +"line. That line specifies the interpreter program for the script. Due to " +"the shebang line, the script can be invoked exactly like a binary program " +"provided that it has the execute bit set. (See man:chmod[1].) For example, " +"a system admin can run our script manually, from the command line:" +msgstr "" +"➊ Um script interpretado deve começar com a linha mágica \"shebang\". " +"Essa linha especifica o programa interpretador para o script. Devido à linha " +"shebang, o script pode ser invocado exatamente como um programa binário, " +"desde que tenha o bit de execução definido. (Veja man:chmod[1].) Por " +"exemplo, um administrador do sistema pode executar nosso script manualmente, " +"a partir da linha de comando:" + +#. type: delimited block . 4 +#: documentation/content/en/articles/rc-scripting/_index.adoc:156 +#, no-wrap +msgid "# /etc/rc.d/dummy start\n" +msgstr "# /etc/rc.d/dummy start\n" + +#. type: delimited block = 4 +#: documentation/content/en/articles/rc-scripting/_index.adoc:162 +msgid "" +"In order to be properly managed by the [.filename]#rc.d# framework, its " +"scripts need to be written in the man:sh[1] language. If you have a service " +"or port that uses a binary control utility or a startup routine written in " +"another language, install that element in [.filename]#/usr/sbin# (for the " +"system) or [.filename]#/usr/local/sbin# (for ports) and call it from a man:" +"sh[1] script in the appropriate [.filename]#rc.d# directory." +msgstr "" +"Para ser gerenciado corretamente pelo framework [.filename]#rc.d#, os " +"scripts devem ser escritos na linguagem man:sh[1]. Se você tiver um serviço " +"ou port que usa um utilitário de controle binário ou uma rotina de " +"inicialização escrita em outra linguagem, instale esse elemento em [." +"filename]#/usr/sbin# (para o sistema) ou [.filename]#/usr/local/sbin# (para " +"ports) e chame-o a partir de um script man:sh[1] no diretório [.filename]#rc." +"d# apropriado." + +#. type: delimited block = 4 +#: documentation/content/en/articles/rc-scripting/_index.adoc:167 +msgid "" +"If you would like to learn the details of why [.filename]#rc.d# scripts must " +"be written in the man:sh[1] language, see how [.filename]#/etc/rc# invokes " *** 1909 LINES SKIPPED *** From nobody Sun Apr 30 12:45:42 2023 X-Original-To: dev-commits-doc-all@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4Q8R0726rdz47mQ0 for ; Sun, 30 Apr 2023 12:45:43 +0000 (UTC) (envelope-from git@FreeBSD.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Q8R071SYBz4Mxt; Sun, 30 Apr 2023 12:45:43 +0000 (UTC) (envelope-from git@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1682858743; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=hrCvxKASUeLW8sQmvzSjJvzRNSjuoX7u9DM9kNGTMvI=; b=WS9imciZRM+2iriLIoMWbTSXYUgmHYBQjSQcwceUkhusig7M5kwXqURrjyksgh018bfIow BHcP/rEW4iEaGsUadS06bAs/rbiIti6+CgdVdhCqT7iF+Mr+K6ZVY9NwCL+z3iZcTNZdLA yq+K3UzJC+G4scWWd2dAQ8/8f5WUJxBFl4OXVEnOOBILYENT7d4kLKM4cj9KEX5OysY4M3 8T4dfk2WIn1j6DY+oUzlKtNERT4sOTmID6ZA+llzL6MwTv9aGNbK0UqrBF8qRX1ediPN3t X7jR2RBEesoN3nwwR6k3gBAVOkjza3L5GRk2gjwOLwGxOetpgzVVqTT6s8l8zw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1682858743; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=hrCvxKASUeLW8sQmvzSjJvzRNSjuoX7u9DM9kNGTMvI=; b=uHkNsX/5rt7Iq3y57VEIgPgDwgbB3E0Ieg6qdkIqTt7JE5qdSboOee6EfIS+rEV9PzyoI2 A5958Rpnd4aZx2eQ89XYHPKPJiByM5sHpkzfToLiZiACHRl/kGZ2Pg5qF5JkTUEzihhsTx EJwKzFwHstoEEAJpkla432WVmjoa48j8QdE9P+vUotzxZsKPVrF/RGWDN9chM1ML/iDe1K 9wqExXJfydaaorsLVVhPw0TAhoy3PfxybkbJrUsb6qmEcNZX1vBlKTYvrVc8P/6YefaAb9 hP7J+f9nQlMwbThJt3HW+5o3Qh3i7av503AJeM7oanBrL10T5KmRr+4QS4Q8oA== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1682858743; a=rsa-sha256; cv=none; b=ymI2yZOTTOeHZgSXXemmsTBsIeYXSE3BZw9879031H2Z3XriiP87o4r+OdHRB0NEhr+8MH iBH4+TRmvTozpFDIHDtvT+MUnTKq2Ets2aGY4s6UTAyux2SyopF9ekTt7orQlK6zoWs/ix slAAAzieZQz01rx9ekgClkrpEIFShPBl/YqcWZh6a6WnCBz0ZuVHZYcv5+UDjNnYebW2Kw ZwB7+WTwvlIdjgNt0Qk6uEiQvT/3JiQA7gElfO/vsk8aG+rzpdhejEaAje00bi5PLbu+kx 0QxmPZGCPsae37KmP0AvnHxpGn06VanEboq/goNJDhTBNepdhEBiWrFosRz1fg== Received: from gitrepo.freebsd.org (gitrepo.freebsd.org [IPv6:2610:1c1:1:6068::e6a:5]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 4Q8R070V5HzPVY; Sun, 30 Apr 2023 12:45:43 +0000 (UTC) (envelope-from git@FreeBSD.org) Received: from gitrepo.freebsd.org ([127.0.1.44]) by gitrepo.freebsd.org (8.16.1/8.16.1) with ESMTP id 33UCjh4j050093; Sun, 30 Apr 2023 12:45:43 GMT (envelope-from git@gitrepo.freebsd.org) Received: (from git@localhost) by gitrepo.freebsd.org (8.16.1/8.16.1/Submit) id 33UCjgev050092; Sun, 30 Apr 2023 12:45:42 GMT (envelope-from git) Date: Sun, 30 Apr 2023 12:45:42 GMT Message-Id: <202304301245.33UCjgev050092@gitrepo.freebsd.org> To: doc-committers@FreeBSD.org, dev-commits-doc-all@FreeBSD.org From: Edson Brandi Subject: git: 6a44ec88c5 - main - Article hubs translated to pt_BR and synced with doc tree version 98c736dd127a2096dc08252d1082300f2ec28ab5 List-Id: Commit messages for all branches of the doc repository List-Archive: https://lists.freebsd.org/archives/dev-commits-doc-all List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-dev-commits-doc-all@freebsd.org X-BeenThere: dev-commits-doc-all@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Git-Committer: ebrandi X-Git-Repository: doc X-Git-Refname: refs/heads/main X-Git-Reftype: branch X-Git-Commit: 6a44ec88c583e00ad148a214389b631e5813675f Auto-Submitted: auto-generated X-ThisMailContainsUnwantedMimeParts: N The branch main has been updated by ebrandi: URL: https://cgit.FreeBSD.org/doc/commit/?id=6a44ec88c583e00ad148a214389b631e5813675f commit 6a44ec88c583e00ad148a214389b631e5813675f Author: Edson Brandi AuthorDate: 2023-04-30 12:44:51 +0000 Commit: Edson Brandi CommitDate: 2023-04-30 12:44:51 +0000 Article hubs translated to pt_BR and synced with doc tree version 98c736dd127a2096dc08252d1082300f2ec28ab5 --- .../content/pt-br/articles/hubs/_index.adoc | 167 +-- .../content/pt-br/articles/hubs/_index.po | 1214 ++++++++++++++++++++ 2 files changed, 1312 insertions(+), 69 deletions(-) diff --git a/documentation/content/pt-br/articles/hubs/_index.adoc b/documentation/content/pt-br/articles/hubs/_index.adoc index 5394751238..77afd9c3e4 100644 --- a/documentation/content/pt-br/articles/hubs/_index.adoc +++ b/documentation/content/pt-br/articles/hubs/_index.adoc @@ -1,14 +1,20 @@ --- -title: Espelhando o FreeBSD authors: - - author: Jun Kuriyama + - + author: 'Jun Kuriyama' email: kuriyama@FreeBSD.org - - author: Valentino Vaschetto + - + author: 'Valentino Vaschetto' email: logo@FreeBSD.org - - author: Daniel Lang + - + author: 'Daniel Lang' email: dl@leo.org - - author: Ken Smith + - + author: 'Ken Smith' email: kensmith@FreeBSD.org +description: 'O guia completo para espelhar o site do FreeBSD, servidores FTP e muito mais' +tags: ["Mirroring", "FreeBSD", "Hub"] +title: 'Espelhando o FreeBSD' trademarks: ["freebsd", "general"] --- @@ -60,7 +66,7 @@ Nós não estamos aceitando novos sites espelho neste momento. [[mirror-contact]] == Informações de contato -Os Coordenadores do Sistema de Espelhamento podem ser contatados pelo email mailto:mirror-admin@FreeBSD.org[mirror-admin@FreeBSD.org]. Existe também uma http://lists.FreeBSD.org/mailman/listinfo/freebsd-hubs[lista de discussão de sites espelho do FreeBSD]. +Os coordenadores do Sistema de Espelhamento podem ser contatados por e-mail através de mailto:mirror-admin@FreeBSD.org[mirror-admin@FreeBSD.org]. Também existe a {freebsd-hubs}. [[mirror-requirements]] == Requisitos para um site espelho do FreeBSD @@ -68,74 +74,74 @@ Os Coordenadores do Sistema de Espelhamento podem ser contatados pelo email mail [[mirror-diskspace]] === Espaço em disco -O espaço em disco é um dos requisitos mais importantes. Dependendo do conjunto de releases, arquiteturas e grau de cobertura que você deseja espelhar, uma quantidade enorme de espaço em disco pode ser consumida. Também tenha em mente que espelhos _oficiais_ provavelmente precisam ser completos. As páginas web devem ser sempre espelhadas completamente. Observe também que os números indicados aqui refletem o estado atual (para 10.4-RELEASE/11.2-RELEASE). Desenvolvimentos adicionais e novas releases só aumentarão a quantidade necessária. Também certifique-se de ter algum espaço extra (cerca de 10-20%) apenas para ter certeza de que não irá faltar espaço. Aqui estão alguns números aproximados: +O espaço em disco é um dos requisitos mais importantes. Dependendo do conjunto de versões, arquiteturas e grau de completude que você deseja espelhar, uma enorme quantidade de espaço em disco pode ser consumida. Além disso, espelhos _oficiais_ provavelmente precisam ser completos. As páginas da web devem sempre ser espelhadas completamente. Observe também que os números aqui declarados refletem o estado atual (em {rel120-current}-RELEASE/{rel113-current}-RELEASE). O desenvolvimento e os lançamentos futuros só aumentarão a quantidade necessária. Certifique-se também de manter cerca de 10-20% de espaço extra apenas para garantir. Aqui estão alguns números aproximados: * Distribuição FTP completa: 1.4 TB * Deltas do CTM: 10 GB * Páginas Web: 1GB -O uso atual de disco da Distribuição por FTP pode ser encontrado em link:ftp://ftp.FreeBSD.org/pub/FreeBSD/dir.sizes[ftp://ftp.FreeBSD.org/pub/FreeBSD/dir.sizes]. +O uso atual de disco da distribuição FTP pode ser encontrado em link:ftp://ftp.FreeBSD.org/pub/FreeBSD/dir.sizes[ftp://ftp.FreeBSD.org/pub/FreeBSD/dir.sizes]. [[mirror-bandwidth]] === Conexão de Rede/Largura de Banda Claro, você precisa estar conectado à Internet. A largura de banda necessária depende do uso pretendido do site espelho. Se você quiser espelhar apenas algumas partes do FreeBSD para uso na sua rede local/intranet, a demanda pode ser muito menor do que se você quiser disponibilizar os arquivos publicamente. Se você pretende se tornar um site espelho oficial, a largura de banda necessária será ainda maior. Podemos apenas dar estimativas aproximadas aqui: -* Site local, sem acesso público: basicamente sem valor mínimo, mas se for menor que < 2 Mbps, pode deixar a sincronização bem lenta. -* Site público não oficial: 34 Mbps é provavelmente um bom começo. -* Site oficial: > 100 Mbps é recomendado, e seu host deve estar conectado o mais próximo possível do seu roteador de borda. +* Site local, sem acesso público: basicamente não há mínimo, mas menos de 2 Mbps pode tornar a sincronização muito lenta. +* Site público não oficial: 34 Mbps provavelmente é um bom começo. +* Site oficial: é recomendado ter mais de 100 Mbps, e seu host deve estar conectado o mais próximo possível do seu roteador de borda. [[mirror-system]] === Requisitos de Sistema, CPU, RAM -Isto depende muito do número esperado de clientes, que é determinado pela política do servidor. O dimensionamento também é afetado pelo tipo de serviços que você deseja oferecer. Serviços FTP ou HTTP simples podem não exigir uma quantidade enorme de recursos. Tenha cuidado se você fornecer o rsync. Isso pode ter um grande impacto nos requisitos de CPU e memória, já que este serviço é considerado um devorador de memória. Os exemplos a seguir, visam lhe dar uma ideia simples deste dimensionamento. +Uma coisa que isso depende é o número esperado de clientes, que é determinado pela política do servidor. Também é afetado pelos tipos de serviços que você deseja oferecer. Serviços FTP ou HTTP simples podem não requerer uma quantidade enorme de recursos. Tenha cuidado se você fornecer o rsync. Isso pode ter um grande impacto nos requisitos de CPU e memória, pois ele é considerado um devorador de memória. Os dados seguintes são apenas exemplos para dar uma ideia aproximada. -Para um site com visitação moderada o qual ofereça o serviço de rsync, você pode considerar uma CPU entre 800 MHz - 1 GHz, e pelo menos 512 MB de memória RAM. Esta é provavelmente a configuração mínima para um site espelho __oficial__. +Para um site moderadamente visitado que oferece rsync, você pode considerar uma CPU atual com cerca de 800 MHz - 1 GHz e pelo menos 512MB de RAM. Isso provavelmente é o mínimo que você deseja para um site _oficial_. Para um site com visitação frequente, você definitivamente vai precisar de mais memória RAM (considere 2 GB como um bom ponto de partida) e possivelmente de mais poder de processamento (CPU), o que pode significar que você precisará ir para um sistema multiprocessado (SMP). -Você também pode querer considerar um subsistema de disco rápido. As operações no repositório SVN requerem um subsistema de disco rápido (o RAID é altamente recomendado). Um controlador SCSI que possua um cache próprio também pode acelerar as coisas, já que a maioria desses serviços incorrem em um grande número de pequenas modificações no disco. +Você também deve considerar um subsistema de disco rápido. As operações no repositório SVN requerem um subsistema de disco rápido (RAID é altamente recomendado). Um controlador SCSI que tenha seu próprio cache também pode acelerar as coisas, uma vez que a maioria desses serviços incorre em um grande número de pequenas modificações no disco. [[mirror-services]] === Serviços para oferecer -Todo site espelho é obrigado a disponibilizar um conjunto de serviços básicos. Em adição a estes serviços obrigatórios, existe um grande número de serviços opcionais aos quais o administrador do servidor pode optar por oferecer. Esta sessão irá detalhar quais serviços você pode oferecer, bem como implementá-los. +Cada site espelho deve ter um conjunto de serviços básicos disponíveis. Além desses serviços obrigatórios, há vários serviços opcionais que os administradores de servidor podem escolher oferecer. Esta seção explica quais serviços você pode fornecer e como implementá-los. [[mirror-serv-ftp]] ==== FTP (necessário para o conjunto de arquivos do FTP) -Este é um dos serviços mais básicos, e ele é obrigatório em todos os sites espelhos que oferecem acesso público às distribuições via FTP. O acesso ao FTP deve ser anônimo, e não é permitido o uso de nenhum controle nas taxas de upload/download (o que seria uma coisa ridícula de qualquer maneira). Não é necessário ter o upload de arquivos habilitado (e isso _nunca_ deve ser permitido na área onde os arquivos do FreeBSD são mantidos). Os arquivos do FreeBSD devem ficar disponíveis sob o caminho [.filename]#/pub/FreeBSD#. +Este é um dos serviços mais básicos e é necessário para cada espelho que oferece distribuições por meio de FTP publico. O acesso FTP deve ser anônimo e não são permitidas proporções de upload/download (algo ridículo de qualquer maneira). A capacidade de upload não é necessária (e _nunca_ deve ser permitida para o espaço de arquivos do FreeBSD). Além disso, os arquivos do FreeBSD devem estar disponíveis sob o caminho [.filename]#/pub/FreeBSD#. -Existem diversos softwares disponíveis que podem ser configurados para operar como um servidor de FTP anônimo. Por exemplo (em ordem alfabética) +Existem diversos softwares disponíveis que podem ser configurados para operar como um servidor de FTP anônimo. Por exemplo (em ordem alfabética). -* `/usr/libexec/ftpd`: o próprio ftpd do FreeBSD pode ser usado. Não deixe de ler o manual do man:ftpd[8]. -* package:ftp/ncftpd[]: Um pacote comercial, grátis para uso educacional. -* package:ftp/oftpd[]: Um ftpd projetado tendo a segurança como foco principal. +* `/usr/libexec/ftpd`: O próprio ftpd do FreeBSD pode ser usado. Certifique-se de ler man:ftpd[8]. +* package:ftp/ncftpd[] Um pacote comercial, gratuito para uso educacional. +* package:ftp/oftpd[]: Um servidor FTP projetado com segurança como foco principal. * package:ftp/proftpd[]: Um ftpd modular e muito flexível. -* package:ftp/pure-ftpd[]: Outro ftpd desenvolvido com segurança em mente. -* package:ftp/twoftpd[]: Mais um ftpd desenvolvido com segurança em mente. -* package:ftp/vsftpd[]: Um ftpd "muito seguro". +* package:ftp/pure-ftpd[]: Outro servidor FTP desenvolvido com segurança em mente. +* package:ftp/twoftpd[]: Como acima. +* package:ftp/vsftpd[]: O ftpd "muito seguro". -O ftpd nativo do FreeBSD, o proftpd, e talvez o ncftpd são alguns dos servidores de FTP mais utilizados. Os demais não possuem uma grande base de usuários entre os sites espelhos. Um item a ser considerado é que você pode precisar de flexibilidade para controlar quantas conexões simultâneas serão permitidas no servidor, limitando desta forma o consumo do seu link IP e dos demais recursos do sistema. +O `ftpd` do FreeBSD, o `proftpd` e talvez o `ncftpd` estão entre os FTPds mais comumente usados. Os outros não têm uma grande base de usuários entre os sites espelho. Uma coisa a considerar é que você pode precisar de flexibilidade para limitar quantas conexões simultâneas são permitidas, limitando assim quanto de largura de banda de rede e recursos do sistema são consumidos. [[mirror-serv-rsync]] ==== Rsync (opcional para o conjunto de arquivos do FTP) -O rsync é muitas vezes oferecido para acesso ao conteúdo da área de FTP de um site espelho do FreeBSD, desta forma outros sites espelhos podem utilizar o seu sistema como fonte para se espelhar. O protocolo do rsync é diferente do FTP em muitos aspectos. Ele é muito mais amigável em relação ao consumo de banda IP, uma vez que quando um arquivo é alterado ao invés de transferí-lo por completo novamente, ele transfere apenas as diferenças entre as duas versões do arquivo. O rsync requer uma grande quantidade de memória para cada instância. A quantidade de memória alocada depende do tamanho do modulo sincronizado em termos do número de diretórios e de arquivos. O rsync pode utilizar `rsh` e o `ssh` (que agora é padrão) para transporte dos dados, ou então utilizar o seu próprio protocolo para acesso stand-alone (este é o método preferido para um servidor público de Rsync). Obrigatoriedade de autenticação, limites ao número de conexões simultâneas e outras r estrições podem ser aplicadas. Há apenas um pacote de software disponível para se implementar um servidor de Rsync: +O Rsync é frequentemente oferecido para acesso ao conteúdo da área FTP do FreeBSD, para que outros sites espelho possam usar seu sistema como fonte. O protocolo é diferente do FTP de muitas maneiras. É muito mais amigável para a largura de banda, pois apenas as diferenças entre os arquivos são transferidas em vez de arquivos inteiros quando são alterados. O Rsync requer uma quantidade significativa de memória para cada instância. O tamanho depende do tamanho do módulo sincronizado em termos do número de diretórios e arquivos. O Rsync pode usar `rsh` e `ssh` (agora padrão) como transporte ou usar seu próprio protocolo para acesso autônomo (este é o método preferido para servidores Rsync públicos). A autenticação, limites de conexão e outras restrições podem ser aplicadas. Há apenas um pacote de software disponível: * package:net/rsync[] [[mirror-serv-http]] ==== HTTP (necessário para as páginas web, opcional para o conjunto de arquivos do FTP) -Se você deseja disponibilizar as páginas web do FreeBSD, você vai precisar instalar um servidor web. Opcionalmente você poderá oferecer acesso a sua árvore de FTP via HTTP. A escolha do software do servidor web é uma escolha do administrador do site espelho. As opções mais populares são: +Se você deseja oferecer as páginas web do FreeBSD, precisará instalar um servidor web. Você pode opcionalmente oferecer o conjunto de arquivos FTP via HTTP. A escolha do software do servidor web é deixada a critério do administrador do espelho. Algumas das opções mais populares são: -* package:www/apache24[]: O Apache é o servidor web mais amplamente utilizado na internet. Ele é usado extensivamente pelo projeto FreeBSD. -* package:www/boa[]: O Boa é um servidor HTTP single-task. Ao contrário dos servidores Web tradicionais, o seu processo não se divide para cada conexão de entrada e nem cria muitas cópias de si mesmo para lidar com várias conexões. Entretanto, ele fornece um desempenho excelente para conteúdo puramente estático. -* package:www/cherokee[]: O >Cherokee é um servidor web muito rápido, flexível e fácil de configurar. Ele suporta as tecnologias difundidas atualmente: FastCGI, SCGI, PHP, CGI, conexões criptografadas por SSL/TLS, vhosts, autenticação de usuários, codificação on the fly e balanceamento de carga. Ele também gera arquivos de log compatíveis com o Apache. +* package:www/apache24[]: O Apache ainda é um dos servidores da Web mais amplamente implantados na Internet. Ele é usado extensivamente pelo Projeto FreeBSD. +* package:www/boa[]: O Boa é um servidor HTTP de single-task. Ao contrário dos servidores web tradicionais, ele não faz um fork para cada conexão recebida, nem faz muitas cópias de si mesmo para lidar com várias conexões. contudo, ele deve fornecer um desempenho consideravelmente melhor para conteúdo puramente estático. +* package:www/cherokee[]: O Cherokee é um servidor web muito rápido, flexível e fácil de configurar. Ele suporta as tecnologias amplamente utilizadas hoje em dia: FastCGI, SCGI, PHP, CGI, conexões criptografadas SSL/TLS, vhosts, autenticação de usuários, codificação on the fly e balanceamento de carga. Ele também gera arquivos de log compatíveis com o Apache. * package:www/lighttpd[]: O lighttpd é um servidor web seguro, rápido, compatível com os padrões e muito flexível o qual foi otimizado para ambientes de alto desempenho. Tem um consumo de memória muito baixo em comparação com outros servidores Web, bem como um baixo consumo de CPU. -* package:www/nginx[]: O nginx é um servidor web de alto desempenho com baixo consumo de memória e recursos-chave para construir uma infraestrutura web moderna e eficiente. Os recursos incluem um servidor HTTP, proxy reverso de HTTP e email, armazenamento em cache, balanceamento de carga, compactação, limitação de solicitações, multiplexação e reutilização de conexões, descarregamento de SSL e streaming de mídia por HTTP. -* package:www/thttpd[]: Se você estiver servindo uma grande quantidade de conteúdo estático, você pode descobrir que usar uma aplicação como o thttpd é mais eficiente do que outros servidores web. Ele também é otimizado para ter um excelente desempenho no FreeBSD. +* package:www/nginx[]: O nginx é um servidor web de borda de alta performance com uma pegada de memória baixa e recursos importantes para construir uma infraestrutura web moderna e eficiente. Os recursos incluem um servidor HTTP, proxy reverso HTTP e de e-mail, cache, balanceamento de carga, compressão, limitação de solicitações, multiplexação e reutilização de conexões, offload SSL e streaming de mídia HTTP. +* package:www/thttpd[]: Se você vai servir uma grande quantidade de conteúdo estático, pode descobrir que usar um aplicativo como o thttpd é mais eficiente do que outros. Ele também é otimizado para ter um excelente desempenho no FreeBSD. [[mirror-howto]] == Como espelhar o FreeBSD @@ -145,65 +151,86 @@ Ok, agora você conhece os requisitos e sabe como oferecer os serviços, mas nã [[mirror-ftp-rsync]] === Espelhando o site FTP -A área FTP possui a maior quantidade de dados a serem espelhados. Ela inclui os _conjuntos de distribuição_ necessários para a instalação em rede, os _branches_ que são snapshots das árvores de código fonte, as _Imagens ISO_ para gravar CD-ROMs com a distribuição de instalação, um sistema de arquivos ativo e um snapshot da árvore de ports. E claro, tudo isso para as várias versões do FreeBSD e diversas arquiteturas. +A área FTP possui a maior quantidade de dados que precisa ser espelhada. Inclui os _conjuntos de distribuição_ necessários para instalação via rede, os _branches_, que são na verdade snapshots dos diretórios de código fonte, as _imagens ISO_ para gravar CD-ROMs com a distribuição de instalação, um sistema de arquivos live (ao vivo) e um snapshot da árvore de ports. Tudo, é claro, para várias versões do FreeBSD e várias arquiteturas. -A melhor maneira de espelhar a área FTP é com o rsync. Você pode instalar o port package:net/rsync[] e então usar o rsync para sincronizar com seu host upstream. O rsync já foi mencionado em <>. Como o acesso rsync não é necessário, seu site de upstream preferido pode não permitir isso. Talvez você precise procurar um pouco mais para localizar um site que permita acesso por rsync. +A melhor maneira de espelhar a área FTP é com o rsync. Você pode instalar o pacote pelo port: net/rsync[] e, em seguida, usar o rsync para sincronizar com seu host upstream. O rsync já foi mencionado em <>. Como o acesso rsync não é obrigatório, seu site upstream preferido pode não permiti-lo. Você pode precisar procurar um pouco para encontrar um site que permita o acesso rsync. [NOTE] ==== -Como o número de clientes rsync terá um impacto significativo na performance do servidor, a maioria dos administradores impõe limitações em seus servidores. Para um espelho, você deve perguntar ao mantenedor do site com o qual você está sincronizando sobre sua política, e talvez pedir uma exceção para o seu host (já que você também é um site espelho). +Como o número de clientes rsync terá um impacto significativo no processamento do servidor, a maioria dos administradores impõe limitações em seu servidor. Para um espelho, você deve perguntar ao mantenedor do site de onde está sincronizando sobre sua política e talvez pedir uma exceção para seu host (já que você é um espelho). ==== Um exemplo de linha de comando para espelhar o FreeBSD pode ser verificada abaixo: -[source,shell] +[source, shell] .... % rsync -vaHz --delete rsync://ftp4.de.FreeBSD.org/FreeBSD/ /pub/FreeBSD/ .... -Consulte a documentação do rsync, que também está disponível em http://rsync.samba.org/[http://rsync.samba.org/], sobre as várias opções a serem usadas com o rsync. Se você sincronizar o módulo inteiro (diferentemente dos subdiretórios), esteja ciente de que o diretório do módulo (aqui "FreeBSD") não será criado, então você não pode omitir o diretório de destino. Além disso, você pode querer configurar um script que chame tal comando via man:cron[8]. +Consulte a documentação do rsync, que também está disponível em http://rsync.samba.org/[http://rsync.samba.org/], sobre as várias opções a serem usadas com o rsync. Se você sincronizar o módulo inteiro (ao contrário de subdiretórios), esteja ciente de que o diretório do módulo (aqui "FreeBSD") não será criado, portanto, você não pode omitir o diretório de destino. Além disso, você pode querer configurar um framework de script que chame esse comando via man:cron[8]. [[mirror-www]] === Espelhando as páginas WWW -O site do FreeBSD deve ser espelhado apenas via rsync. +[WARNING] +==== +Desde a migração da documentação para Hugo/Asciidoctor em 25/01/2021, a sincronização do site com rsync não funciona mais. +==== -Uma linha de comando para espelhar o site do FreeBSD pode parecer com: +Existem estudos em andamento para implementar um espelho do website com extref:{handbook}mirrors/[infraestrutura oficial]. +Para os antigos espelhos do website, uma maneira de obter o espelhamento hoje em dia é construir o site localmente com o endereço correspondente em que será hospedado. + +[source, shell] +.... +% cd website && env HUGO_baseURL="https://www.XX.freebsd.org/" make +.... + +Verifique mais detalhes sobre as ferramentas de construção no livro extref:{fdp-primer}overview/[Primer do Projeto de Documentação do FreeBSD para Novos Contribuidores, overview-quick-start]. + +//// [source,shell] .... % rsync -vaHz --delete rsync://bit0.us-west.freebsd.org/FreeBSD-www-data/ /usr/local/www/ .... +//// + +[NOTE] +==== +Observe que o site foi dividido em www.FreeBSD.org e docs.FreeBSD.org, e existem links entre eles; além disso, no momento, a variável `HUGO_baseURL` não cobrirá todos os links, dessa forma, o espelhamento do site não é encorajado. +==== [[mirror-pkgs]] === Espelhando os Pacotes -Devido a exigências muito altas de largura de banda, armazenamento e administração, o Projeto FreeBSD decidiu não permitir espelhos públicos de pacotes. Para sites com muitas máquinas, pode ser vantajoso executar um proxy HTTP para fazer cache do man:pkg[8]. Alternativamente, pacotes específicos e suas dependências podem ser baixados executando algo assim: +Devido aos requisitos muito altos de largura de banda, armazenamento e administração, o Projeto FreeBSD decidiu não permitir espelhos públicos de pacotes pré compilados. Para sites com muitas máquinas, pode ser vantajoso executar um proxy HTTP com cache habilitado para o processo man:pkg[8]. Alternativamente, pacotes específicos e suas dependências podem ser baixados executando algo como o seguinte: -[source,shell] +[source, shell] .... % pkg fetch -d -o /usr/local/mirror vim .... Quando esses pacotes forem baixados, os metadados do repositório devem ser gerados executando: -[source,shell] +[source, shell] .... % pkg repo /usr/local/mirror .... -Uma vez que os pacotes tenham sido baixados e os metadados para o repositório tenham sido gerados, sirva os pacotes até as máquinas clientes via HTTP. Para obter informações adicionais, consulte as páginas de manual do man:pkg[8], mais especificamente a página man:pkg-repo[8]. +Depois que os pacotes forem baixados e os metadados do repositório forem gerados, sirva os pacotes para as máquinas clientes via HTTP. Para obter informações adicionais, consulte as páginas man do man:pkg[8], especificamente a página man:pkg-repo[8]. [[mirror-how-often]] -=== Com que frequência eu devo atualizar o conteúdo do meu espelho? +=== Com que frequência eu devo atualizar o conteúdo do meu site espelho? -Todo site espelho deve ser atualizado no mínimo uma vez por dia. Certamente, um script com bloqueio para impedir que várias execuções ocorram ao mesmo tempo será necessário para executar a partir do man:cron[8]. Como quase todo administrador faz isso à sua maneira, instruções específicas não podem ser fornecidas. Mas poderia ser algo como: +Todo espelho deve ser atualizado pelo menos uma vez por dia. Certamente, um script com bloqueio para evitar que várias execuções ocorram ao mesmo tempo será necessário para ser executado pelo man:cron[8]. Como cada administrador faz isso de sua própria maneira, instruções específicas não podem ser fornecidas. Este processo poderia funcionar , por exemplo, desta forma: [.procedure] -. Coloque o comando para executar seu aplicativo de espelhamento em um script. Recomenda-se o uso de um script simples `/bin/sh`. +==== +. Coloque o comando para executar sua aplicação de espelhamento em um script. O uso de um script `/bin/sh` simples é recomendado. . Adicione alguns redirecionamentos de saída para que as mensagens de diagnóstico sejam registradas em um arquivo. . Teste se o seu script funciona. Verifique os logs. -. Use o man:crontab[1] para adicionar o script ao man:crontab[5] do usuário apropriado. Este deve ser um usuário diferente daquele sob o qual o daemon FTP está sendo executado, de forma que, se as permissões de arquivo dentro de sua área FTP não forem legíveis por todos, esses arquivos não poderão ser acessados ​​por FTP anônimo. Isto é usado para fazer o "stage" de uma release - assegurando que todos os sites espelhos oficiais tenham todos os arquivos necessários da release no dia do lançamento. +. Use o man:crontab[1] para adicionar o script ao man:crontab[5] do usuário apropriado. Este deve ser um usuário diferente do que seu daemon FTP é executado, para que, se as permissões de arquivo dentro de sua área FTP não forem legíveis por todo o mundo, esses arquivos não possam ser acessados pelo FTP anônimo. Isso é usado para "preparar" as releases - garantindo que todos os sites de espelho oficiais tenham todos os arquivos da release necessários no dia do seu lançamento. +==== Aqui estão alguns agendamentos recomendados: @@ -211,43 +238,45 @@ Aqui estão alguns agendamentos recomendados: * Páginas WWW: diariamente [[mirror-where]] -== De onde espelhar +== De onde fazer o espelhamento -Esta é uma questão importante. Então, esta seção vai gastar algum esforço para explicar mais a fundo. Nós diremos isso várias vezes: sob nenhuma circunstância você deve espelhar a partir do `ftp.FreeBSD.org`. +Esta é uma questão importante. Portanto, esta seção dedicará algum esforço para explicar o os motivos que estão por trás desta orientação. Diremos isso várias vezes: em nenhuma circunstância você deve espelhar a partir de `ftp.FreeBSD.org`. [[mirror-where-organization]] === Algumas palavras sobre a organização -Os espelhos são organizados por país. Todos os espelhos oficiais possuem uma entrada de DNS no formato `ftpN.CC.FreeBSD.org`. O _CC_ (ou seja, o código do país) é o _domínio de nível superior_ (TLD) do país onde esse espelho está localizado. _N_ é um número, dizendo que o host seria o espelho _Nth_ daquele país. (O mesmo se aplica a `wwwN.CC.FreeBSD.org`, etc.) Há espelhos sem partes __CC__. Esses são os sites espelhos que são muito bem conectados e permitem um grande número de usuários simultâneos. O `ftp.FreeBSD.org` é na verdade duas máquinas, uma atualmente localizada na Dinamarca e outra nos Estados Unidos. Este _NÃO_ é um site mestre e nunca deve ser usado para se espelhar. Muitos documentos on-line conduzem os usuários "interativos" para `ftp.FreeBSD.org`, portanto os sistemas automatizados de espelhamento devem utilizar uma máquina diferente para se espelhar. +Os espelhos são organizados por país. Todos os espelhos oficiais têm uma entrada DNS com a forma `ftpN.CC.FreeBSD.org`. _CC_ (ou seja, código do país) é o _domínio de nível superior_ (TLD) do país onde esse espelho está localizado. _N_ é um número, indicando que o host seria o _N-ésimo_ espelho nesse país. (O mesmo se aplica a `wwwN.CC.FreeBSD.org`, etc.) Existem espelhos sem a parte _CC_. Esses são os sites de espelho que estão muito bem conectados e permitem um grande número de usuários simultâneos. O `ftp.FreeBSD.org` na verdade são duas máquinas, uma atualmente localizada na Dinamarca e outra nos Estados Unidos. Não é um site principal e nunca deve ser usado para se espelhar a partir dele. Muita documentação online direciona usuários "interativos" para `ftp.FreeBSD.org`, portanto, sistemas automatizados de espelhamento devem encontrar um servidor diferente para espelhar. -Além disso, existe uma hierarquia de espelhos, descrita em termos de __camadas__. Os sites mestres não são referenciados, mas podem ser descritos como __Tier-0__. Espelhos que espelham desses sites podem ser considerados __Tier-1__, espelhos de __Tier-1__mirrors, são__Tier-2__, etc. Os sites oficiais são encorajados a ter um _nível_ baixo, mas quanto mais baixo o nível, maiores os requisitos em termos, conforme descrito em <>. Também o acesso a espelhos de baixo nível pode ser restrito, e o acesso a sites mestres é definitivamente restrito. A __tier__-hierarchy não é refletida pelo DNS e geralmente não é documentada em nenhum lugar, exceto nos sites mestres. No entanto, os espelhos oficiais com números baixos como 1-4, geralmente são _Tier-1_ (isso é apenas uma dica, e não há regra). +Além disso, existe uma hierarquia de espelhos, que é descrita em termos de __níveis__. Os sites principais não são mencionados, mas podem ser descritos como __Nível-0__. Espelhos que espelham a partir desses sites podem ser considerados __Nível-1__, espelhos de espelhos __Nível-1__ são __Nível-2__, etc. Sites oficiais são incentivados a ter um nível baixo, mas quanto mais baixo o nível, maiores os requisitos como descrito em <>. O acesso a espelhos de baixo nível pode ser restrito e o acesso a sites principais é definitivamente restrito. A hierarquia de __nível__ não é refletida pelo DNS e geralmente não é documentada em nenhum lugar, exceto para os sites principais. No entanto, espelhos oficiais com números baixos como 1-4, geralmente são __Nível-1__ (isso é apenas uma dica aproximada e não há regra). [[mirror-where-where]] === Ok, mas de onde devo baixar os arquivos agora? -Em nenhuma circunstância você deve espelhar a partir de `ftp.FreeBSD.org`. A resposta simples é: do site que está mais próximo de você em termos de Internet ou que lhe ofereça o acesso mais rápido. +Em nenhuma circunstância você deve espelhar a partir de `ftp.FreeBSD.org`. A resposta curta é: a partir do site que estiver mais próximo de você em termos de Internet ou que oferecer o acesso mais rápido. [[mirror-where-simple]] ==== Eu só quero espelhar de algum lugar! -Se você não tem nenhuma intenção ou requisito especial, a declaração em <> se aplica. Isso significa: +Se você não tem intenções ou requisitos especiais, a afirmação em <> se aplica. Isso significa: [.procedure] -. Verifique quais fornecem acesso mais rápido (número de saltos, tempos de ida e volta) e ofereçam os serviços que você pretende usar (como rsync). +==== +. Verifique quais sites oferecem o acesso mais rápido (número de saltos, tempos de ida e volta) e oferecem os serviços que você pretende usar (como rsync). . Entre em contato com os administradores do site escolhido, informando sua solicitação e perguntando sobre seus termos e políticas. -. Configure o seu espelho conforme descrito acima. +. Configure o seu site espelho conforme descrito acima. +==== [[mirror-where-official]] -==== Eu sou um espelho oficial, qual é o site certo para mim? +==== Sou um site espelho oficial, qual é o rito certo para mim? -Em geral, a descrição em <> ainda se aplica. É claro que você pode querer colocar algum peso no fato de que seu upstream deve ser de nível baixo. Existem algumas outras considerações sobre os espelhos _oficiais_ que são descritos em <>. +Em geral, a descrição em <> ainda se aplica. Claro, você pode querer dar mais importância ao fato de que o site upstream deve ter um nível baixo. Existem algumas outras considerações sobre espelhos _oficiais_ que são descritas em <>. [[mirror-where-master]] ==== Eu quero acessar os sites principais! -Se você tiver boas razões e pré-requisitos, poderá querer e obter acesso a um dos sites mestres. O acesso a esses sites é geralmente restrito e existem políticas especiais para acesso. Se você já é um espelho __oficial__, isso certamente irá ajudar você a obter acesso. Em qualquer outro caso, certifique-se de que seu país realmente precisa de outro espelho. Se já tiver três ou mais, pergunte ao "administrador de região"(mailto:hostmaster@CC.FreeBSD.org[hostmaster@CC.FreeBSD.org]) ou http://lists.FreeBSD.org/mailman/listinfo/freebsd-hubs[Listas de discussão de sites espelho do FreeBSD] primeiro. +Se você tiver bons motivos e bons pré-requisitos, poderá querer e obter acesso a um dos sites principais. O acesso a esses sites geralmente é restrito e existem políticas especiais para acesso. Se você já é um espelho _oficial_, certamente isso ajuda a obter acesso. Em qualquer outro caso, certifique-se de que seu país realmente precisa de outro espelho. Se já tiver três ou mais, pergunte ao "administrador de zona" (mailto:hostmaster@CC.FreeBSD.org[hostmaster@CC.FreeBSD.org]) ou na {freebsd-hubs} primeiro. -Quem ajudou você a se tornar um espelho _oficial_ deve ajudar você a obter acesso a um host de upstream apropriado, seja um dos sites mestres ou um site Tier-1 adequado. Caso contrário, você pode enviar um email para mailto:mirror-admin@FreeBSD.org[mirror-admin@FreeBSD.org] para solicitar ajuda com isso. +Quem o ajudou a se tornar um espelho _oficial_ deve ter lhe ajudado a obter acesso a um host upstream apropriado, seja um dos sites principais ou um site Tier-1 adequado. Se não, você pode enviar um e-mail para mailto:mirror-admin@FreeBSD.org[mirror-admin@FreeBSD.org] para solicitar ajuda com isso. Existe um site principal para o conjunto de arquivos FTP. @@ -256,38 +285,38 @@ Existe um site principal para o conjunto de arquivos FTP. Este é o site principal do conjunto de arquivos FTP. -O `ftp-master.FreeBSD.org` fornece acesso por rsync, além do acesso normal por FTP. Consulte <>. +O `ftp-master.FreeBSD.org` disponibiliza acesso via rsync, além do FTP. Consulte <> para obter mais informações. -Os espelhos também são encorajados a permitir acesso por rsync para o conteúdo FTP, já que eles são espelhos de __Tier-1__. +Também é encorajado que os espelhos permitam o acesso ao rsync para o conteúdo FTP, já que eles são espelhos __Tier-1__. [[mirror-official]] == Espelhos Oficiais Espelhos oficiais são os espelhos que -* a) tem uma entrada de DNS `FreeBSD.org` (geralmente um CNAME). +* a) ter uma entrada DNS `FreeBSD.org` (geralmente um CNAME). * b) são listados como um espelho oficial na documentação do FreeBSD (como no Handbook). -Até agora, para distinguir espelhos oficiais. Espelhos oficiais não são necessariamente espelhos __Tier-1__. No entanto, você provavelmente não encontrará um espelho _Tier-1_ que também não é oficial. +Até agora, para distinguir espelhos oficiais. Espelhos oficiais não necessariamente são espelhos __Tier-1__. No entanto, provavelmente você não encontrará um espelho __Tier-1__ que não seja oficial. [[mirror-official-requirements]] === Requisitos especiais para sites espelhos oficiais (Tier-1) -Não é tão fácil declarar os requisitos para todos os sites espelhos oficiais, uma vez que o projeto é um pouco tolerante aqui. É mais fácil dizer o que um _site espelho oficial Tier-1_ precisa ter. Todos os outros sites espelhos oficiais podem considerar isto como um grande __deve__. +Não é tão fácil estabelecer requisitos para todos os espelhos oficiais, já que o projeto é bastante tolerante nesse aspecto. É mais fácil dizer o que é exigido dos _espelhos oficiais de nível 1_. Todos os outros espelhos oficiais devem considerar isso uma grande __recomendação__. Os sites espelhos Tier-1 precisam: * ter o conjunto completo de arquivos * permitir acesso a outros sites espelho -* fornecer acesso por FTP e rsync +* fornecer acesso FTP e rsync -Além disso, os administradores devem estar inscritos nas http://lists.FreeBSD.org/mailman/listinfo/freebsd-hubs[listas de discussão de sites espelho do FreeBSD]. Consulte extref:{handbook}eresources[este link, eresources-mail] para obter detalhes em como se inscrever. +Além disso, os administradores devem se inscrever no {freebsd-hubs}. Consulte extref:{handbook}[este link, eresources-mail] para obter detalhes sobre como se inscrever. [IMPORTANT] ==== -É _muito_ importante para um administrador de hub, especialmente administradores de hub de Tier-1, verificar o https://www.FreeBSD.org/releng/[calendário de lançamentos] para a próxima versão do FreeBSD. Isto é importante porque lhe dirá quando o próximo lançamento está programado para sair, e assim lhe dará tempo para se preparar para o grande pico de tráfego que virá. +É _muito_ importante para um administrador de um site espelho, especialmente administradores de espelhos Tier-1, verificar o https://www.FreeBSD.org/releng/[calendário de lançamento] para o próximo release do FreeBSD. Isso é importante porque informará quando o próximo release está programado para sair, dando tempo para se preparar para o grande aumento de tráfego que o segue. -Também é importante que os administradores do hub tentem manter seus espelhos o mais atualizados possível (novamente, ainda mais importante para os espelhos Tier-1). Se o Mirror1 não for atualizado por um tempo, os espelhos de camada inferior começarão a espelhar os dados antigos do Mirror1 e, portanto, iniciará uma espiral descendente... Mantenha seus espelhos atualizados! +É importante também que os administradores dos hubs tentem manter seus espelhos atualizados o máximo possível (novamente, ainda mais crucial para os espelhos Tier-1). Se o Mirror1 não atualizar por um tempo, os espelhos de nível inferior começarão a espelhar dados antigos do Mirror1 e, assim, começa uma espiral descendente... Mantenha seus espelhos atualizados! ==== [[mirror-official-become]] @@ -303,5 +332,5 @@ Aqui estão os links para as páginas de estatísticas dos seus sites espelho fa [[mirror-statpagesftp]] === Estatísticas do site FTP -* ftp.is.FreeBSD.org - mailto:hostmaster@is.FreeBSD.org[hostmaster@is.FreeBSD.org] - http://www.rhnet.is/status/draupnir/draupnir.html[(Largura de Banda)] http://www.rhnet.is/status/ftp/ftp-notendur.html[(Processos FTP)] http://www.rhnet.is/status/ftp/http-notendur.html[(Processos HTTP)] -* ftp2.ru.FreeBSD.org - mailto:mirror@macomnet.ru[mirror@macomnet.ru] - http://mirror.macomnet.net/mrtg/mirror.macomnet.net_195.128.64.25.html[(Largura de Banda)] http://mirror.macomnet.net/mrtg/mirror.macomnet.net_proc.html[(Usuários HTTP e FTP)] +* ftp.is.FreeBSD.org - mailto:hostmaster@is.FreeBSD.org[hostmaster@is.FreeBSD.org] - http://www.rhnet.is/status/draupnir/draupnir.html[ (Largura de banda)] http://www.rhnet.is/status/ftp/ftp-notendur.html[(Processos FTP)] http://www.rhnet.is/status/ftp/http-notendur.html[(Processos HTTP)] +* ftp2.ru.FreeBSD.org - mailto:mirror@macomnet.ru[mirror@macomnet.ru] - http://mirror.macomnet.net/mrtg/mirror.macomnet.net_195.128.64.25.html[(Largura de banda)] http://mirror.macomnet.net/mrtg/mirror.macomnet.net_proc.html[(Usuários de HTTP e FTP)] diff --git a/documentation/content/pt-br/articles/hubs/_index.po b/documentation/content/pt-br/articles/hubs/_index.po new file mode 100644 index 0000000000..67914e1a32 --- /dev/null +++ b/documentation/content/pt-br/articles/hubs/_index.po @@ -0,0 +1,1214 @@ +# SOME DESCRIPTIVE TITLE +# Copyright (C) YEAR The FreeBSD Project +# This file is distributed under the same license as the FreeBSD Documentation package. +# Danilo G. Baio , 2021. +# Edson Brandi , 2023. +# "Danilo G. Baio" , 2023. +# Wendell Borges , 2023. +msgid "" +msgstr "" +"Project-Id-Version: FreeBSD Documentation VERSION\n" +"POT-Creation-Date: 2022-07-07 23:23-0300\n" +"PO-Revision-Date: 2023-04-30 12:34+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" +"Plural-Forms: nplurals=2; plural=n > 1;\n" +"X-Generator: Weblate 4.17\n" + +#. type: YAML Front Matter: description +#: documentation/content/en/articles/hubs/_index.adoc:1 +#, no-wrap +msgid "The all in one guide for mirroring the FreeBSD website, FTP servers, and more" +msgstr "" +"O guia completo para espelhar o site do FreeBSD, servidores FTP e muito mais" + +#. type: Title = +#: documentation/content/en/articles/hubs/_index.adoc:1 +#: documentation/content/en/articles/hubs/_index.adoc:17 +#, no-wrap +msgid "Mirroring FreeBSD" +msgstr "Espelhando o FreeBSD" + +#. type: Plain text +#: documentation/content/en/articles/hubs/_index.adoc:50 +msgid "Abstract" +msgstr "Resumo" + +#. type: Plain text +#: documentation/content/en/articles/hubs/_index.adoc:52 +msgid "" +"An in-progress article on how to mirror FreeBSD, aimed at hub administrators." +msgstr "" +"Um artigo em andamento sobre como espelhar o FreeBSD, destinado à " +"administradores de hubs." + +#. type: Plain text +#: documentation/content/en/articles/hubs/_index.adoc:54 +msgid "'''" +msgstr "'''" + +#. type: delimited block = 4 +#: documentation/content/en/articles/hubs/_index.adoc:60 +msgid "We are not accepting new mirrors at this time." +msgstr "Nós não estamos aceitando novos sites espelho neste momento." + +#. type: Title == +#: documentation/content/en/articles/hubs/_index.adoc:63 +#, no-wrap +msgid "Contact Information" +msgstr "Informações de contato" + +#. type: Plain text +#: documentation/content/en/articles/hubs/_index.adoc:67 +msgid "" +"The Mirror System Coordinators can be reached through email at mailto:mirror-" +"admin@FreeBSD.org[mirror-admin@FreeBSD.org]. There is also a {freebsd-hubs}." +msgstr "" +"Os coordenadores do Sistema de Espelhamento podem ser contatados por e-mail " +"através de mailto:mirror-admin@FreeBSD.org[mirror-admin@FreeBSD.org]. Também " +"existe a {freebsd-hubs}." + +#. type: Title == +#: documentation/content/en/articles/hubs/_index.adoc:69 +#, no-wrap +msgid "Requirements for FreeBSD Mirrors" +msgstr "Requisitos para um site espelho do FreeBSD" + +#. type: Title === +#: documentation/content/en/articles/hubs/_index.adoc:72 +#, no-wrap +msgid "Disk Space" +msgstr "Espaço em disco" + +#. type: Plain text +#: documentation/content/en/articles/hubs/_index.adoc:82 +msgid "" +"Disk space is one of the most important requirements. Depending on the set " +"of releases, architectures, and degree of completeness you want to mirror, a " +"huge amount of disk space may be consumed. Also keep in mind that " +"_official_ mirrors are probably required to be complete. The web pages " +"should always be mirrored completely. Also note that the numbers stated " +"here are reflecting the current state (at {rel120-current}-RELEASE/{rel113-" +"current}-RELEASE). Further development and releases will only increase the " +"required amount. Also make sure to keep some (ca. 10-20%) extra space " +"around just to be sure. Here are some approximate figures:" +msgstr "" +"O espaço em disco é um dos requisitos mais importantes. Dependendo do " +"conjunto de versões, arquiteturas e grau de completude que você deseja " +"espelhar, uma enorme quantidade de espaço em disco pode ser consumida. Além " +"disso, espelhos _oficiais_ provavelmente precisam ser completos. As páginas " +"da web devem sempre ser espelhadas completamente. Observe também que os " +"números aqui declarados refletem o estado atual (em {rel120-current}-RELEASE/" +"{rel113-current}-RELEASE). O desenvolvimento e os lançamentos futuros só " +"aumentarão a quantidade necessária. Certifique-se também de manter cerca de " +"10-20% de espaço extra apenas para garantir. Aqui estão alguns números " +"aproximados:" + +#. type: Plain text +#: documentation/content/en/articles/hubs/_index.adoc:84 +msgid "Full FTP Distribution: 1.4 TB" +msgstr "Distribuição FTP completa: 1.4 TB" + +#. type: Plain text +#: documentation/content/en/articles/hubs/_index.adoc:85 +msgid "CTM deltas: 10 GB" +msgstr "Deltas do CTM: 10 GB" + +#. type: Plain text +#: documentation/content/en/articles/hubs/_index.adoc:86 +msgid "Web pages: 1GB" +msgstr "Páginas Web: 1GB" + +#. type: Plain text +#: documentation/content/en/articles/hubs/_index.adoc:88 +msgid "" +"The current disk usage of FTP Distribution can be found at link:ftp://ftp." +"FreeBSD.org/pub/FreeBSD/dir.sizes[ftp://ftp.FreeBSD.org/pub/FreeBSD/dir." +"sizes]." +msgstr "" +"O uso atual de disco da distribuição FTP pode ser encontrado em " +"link:ftp://ftp.FreeBSD.org/pub/FreeBSD/dir.sizes[ftp://ftp.FreeBSD.org/pub/" +"FreeBSD/dir.sizes]." + +#. type: Title === +#: documentation/content/en/articles/hubs/_index.adoc:90 +#, no-wrap +msgid "Network Connection/Bandwidth" +msgstr "Conexão de Rede/Largura de Banda" + +#. type: Plain text +#: documentation/content/en/articles/hubs/_index.adoc:97 +msgid "" +"Of course, you need to be connected to the Internet. The required bandwidth " +"depends on your intended use of the mirror. If you just want to mirror some " +"parts of FreeBSD for local use at your site/intranet, the demand may be much " +"smaller than if you want to make the files publicly available. If you " +"intend to become an official mirror, the bandwidth required will be even " +"higher. We can only give rough estimates here:" +msgstr "" +"Claro, você precisa estar conectado à Internet. A largura de banda " +"necessária depende do uso pretendido do site espelho. Se você quiser " +"espelhar apenas algumas partes do FreeBSD para uso na sua rede local/" +"intranet, a demanda pode ser muito menor do que se você quiser " +"disponibilizar os arquivos publicamente. Se você pretende se tornar um site " +"espelho oficial, a largura de banda necessária será ainda maior. Podemos " +"apenas dar estimativas aproximadas aqui:" + +#. type: Plain text +#: documentation/content/en/articles/hubs/_index.adoc:99 +msgid "" +"Local site, no public access: basically no minimum, but < 2 Mbps could make " +"syncing too slow." +msgstr "" +"Site local, sem acesso público: basicamente não há mínimo, mas menos de 2 " +"Mbps pode tornar a sincronização muito lenta." + +#. type: Plain text +#: documentation/content/en/articles/hubs/_index.adoc:100 +msgid "Unofficial public site: 34 Mbps is probably a good start." +msgstr "Site público não oficial: 34 Mbps provavelmente é um bom começo." + +#. type: Plain text +#: documentation/content/en/articles/hubs/_index.adoc:101 +msgid "" +"Official site: > 100 Mbps is recommended, and your host should be connected " +"as close as possible to your border router." +msgstr "" +"Site oficial: é recomendado ter mais de 100 Mbps, e seu host deve estar " +"conectado o mais próximo possível do seu roteador de borda." + +#. type: Title === +#: documentation/content/en/articles/hubs/_index.adoc:103 +#, no-wrap +msgid "System Requirements, CPU, RAM" +msgstr "Requisitos de Sistema, CPU, RAM" + +#. type: Plain text +#: documentation/content/en/articles/hubs/_index.adoc:111 +msgid "" +"One thing this depends on the expected number of clients, which is " +"determined by the server's policy. It is also affected by the types of " +"services you want to offer. Plain FTP or HTTP services may not require a " +"huge amount of resources. Watch out if you provide rsync. This can have a " +"huge impact on CPU and memory requirements as it is considered a memory " +"hog. The following are just examples to give you a very rough hint." +msgstr "" +"Uma coisa que isso depende é o número esperado de clientes, que é " +"determinado pela política do servidor. Também é afetado pelos tipos de " +"serviços que você deseja oferecer. Serviços FTP ou HTTP simples podem não " +"requerer uma quantidade enorme de recursos. Tenha cuidado se você fornecer o " +"rsync. Isso pode ter um grande impacto nos requisitos de CPU e memória, pois " +"ele é considerado um devorador de memória. Os dados seguintes são apenas " +"exemplos para dar uma ideia aproximada." + +#. type: Plain text +#: documentation/content/en/articles/hubs/_index.adoc:114 +msgid "" +"For a moderately visited site that offers rsync, you might consider a " +"current CPU with around 800MHz - 1 GHz, and at least 512MB RAM. This is " +"probably the minimum you want for an _official_ site." +msgstr "" +"Para um site moderadamente visitado que oferece rsync, você pode considerar " +"uma CPU atual com cerca de 800 MHz - 1 GHz e pelo menos 512MB de RAM. Isso " +"provavelmente é o mínimo que você deseja para um site _oficial_." + +#. type: Plain text +#: documentation/content/en/articles/hubs/_index.adoc:116 +msgid "" +"For a frequently used site you definitely need more RAM (consider 2GB as a " +"good start) and possibly more CPU, which could also mean that you need to go " +"for a SMP system." +msgstr "" +"Para um site com visitação frequente, você definitivamente vai precisar de " +"mais memória RAM (considere 2 GB como um bom ponto de partida) e " +"possivelmente de mais poder de processamento (CPU), o que pode significar " +"que você precisará ir para um sistema multiprocessado (SMP)." + +#. type: Plain text +#: documentation/content/en/articles/hubs/_index.adoc:120 +msgid "" +"You also want to consider a fast disk subsystem. Operations on the SVN " +"repository require a fast disk subsystem (RAID is highly advised). A SCSI " +"controller that has a cache of its own can also speed up things since most " +"of these services incur a large number of small modifications to the disk." +msgstr "" +"Você também deve considerar um subsistema de disco rápido. As operações no " +"repositório SVN requerem um subsistema de disco rápido (RAID é altamente " +"recomendado). Um controlador SCSI que tenha seu próprio cache também pode " +"acelerar as coisas, uma vez que a maioria desses serviços incorre em um " +"grande número de pequenas modificações no disco." + +#. type: Title === +#: documentation/content/en/articles/hubs/_index.adoc:122 +#, no-wrap +msgid "Services to Offer" +msgstr "Serviços para oferecer" + +#. type: Plain text +#: documentation/content/en/articles/hubs/_index.adoc:127 +msgid "" +"Every mirror site is required to have a set of core services available. In " +"addition to these required services, there are a number of optional services " +"that server administrators may choose to offer. This section explains which " +"services you can provide and how to go about implementing them." +msgstr "" +"Cada site espelho deve ter um conjunto de serviços básicos disponíveis. Além " +"desses serviços obrigatórios, há vários serviços opcionais que os " +"administradores de servidor podem escolher oferecer. Esta seção explica " +"quais serviços você pode fornecer e como implementá-los." + +#. type: Title ==== +#: documentation/content/en/articles/hubs/_index.adoc:129 +#, no-wrap +msgid "FTP (required for FTP Fileset)" +msgstr "FTP (necessário para o conjunto de arquivos do FTP)" + +#. type: Plain text +#: documentation/content/en/articles/hubs/_index.adoc:135 +msgid "" +"This is one of the most basic services, and it is required for each mirror " +"offering public FTP distributions. FTP access must be anonymous, and no " +"upload/download ratios are allowed (a ridiculous thing anyway). Upload " +"capability is not required (and _must_ never be allowed for the FreeBSD file " +"space). Also the FreeBSD archive should be available under the path [." +"filename]#/pub/FreeBSD#." +msgstr "" +"Este é um dos serviços mais básicos e é necessário para cada espelho que " +"oferece distribuições por meio de FTP publico. O acesso FTP deve ser anônimo " +"e não são permitidas proporções de upload/download (algo ridículo de " +"qualquer maneira). A capacidade de upload não é necessária (e _nunca_ deve " +"ser permitida para o espaço de arquivos do FreeBSD). Além disso, os arquivos " +"do FreeBSD devem estar disponíveis sob o caminho [.filename]#/pub/FreeBSD#." + +#. type: Plain text +#: documentation/content/en/articles/hubs/_index.adoc:137 +msgid "" +"There is a lot of software available which can be set up to allow anonymous " +"FTP (in alphabetical order)." +msgstr "" +"Existem diversos softwares disponíveis que podem ser configurados para " +"operar como um servidor de FTP anônimo. Por exemplo (em ordem alfabética)." + +#. type: Plain text +#: documentation/content/en/articles/hubs/_index.adoc:139 +msgid "" +"`/usr/libexec/ftpd`: FreeBSD's own ftpd can be used. Be sure to read man:" +"ftpd[8]." +msgstr "" +"`/usr/libexec/ftpd`: O próprio ftpd do FreeBSD pode ser usado. Certifique-se " +"de ler man:ftpd[8]." + +#. type: Plain text +#: documentation/content/en/articles/hubs/_index.adoc:140 +msgid "package:ftp/ncftpd[]: A commercial package, free for educational use." +msgstr "" +"package:ftp/ncftpd[] Um pacote comercial, gratuito para uso educacional." + +#. type: Plain text +#: documentation/content/en/articles/hubs/_index.adoc:141 +msgid "package:ftp/oftpd[]: An ftpd designed with security as a main focus." +msgstr "" +"package:ftp/oftpd[]: Um servidor FTP projetado com segurança como foco " +"principal." + +#. type: Plain text +#: documentation/content/en/articles/hubs/_index.adoc:142 +msgid "package:ftp/proftpd[]: A modular and very flexible ftpd." +msgstr "package:ftp/proftpd[]: Um ftpd modular e muito flexível." + +#. type: Plain text +#: documentation/content/en/articles/hubs/_index.adoc:143 +msgid "package:ftp/pure-ftpd[]: Another ftpd developed with security in mind." +msgstr "" +"package:ftp/pure-ftpd[]: Outro servidor FTP desenvolvido com segurança em " +"mente." + +#. type: Plain text +#: documentation/content/en/articles/hubs/_index.adoc:144 +msgid "package:ftp/twoftpd[]: As above." +msgstr "package:ftp/twoftpd[]: Como acima." + +#. type: Plain text +#: documentation/content/en/articles/hubs/_index.adoc:145 +msgid "package:ftp/vsftpd[]: The \"very secure\" ftpd." +msgstr "package:ftp/vsftpd[]: O ftpd \"muito seguro\"." + +#. type: Plain text +#: documentation/content/en/articles/hubs/_index.adoc:149 +msgid "" +"FreeBSD's `ftpd`, `proftpd` and maybe `ncftpd` are among the most commonly " +"used FTPds. The others do not have a large userbase among mirror sites. " +"One thing to consider is that you may need flexibility in limiting how many " +"simultaneous connections are allowed, thus limiting how much network " +"bandwidth and system resources are consumed." +msgstr "" +"O `ftpd` do FreeBSD, o `proftpd` e talvez o `ncftpd` estão entre os FTPds " +"mais comumente usados. Os outros não têm uma grande base de usuários entre " +"os sites espelho. Uma coisa a considerar é que você pode precisar de " +"flexibilidade para limitar quantas conexões simultâneas são permitidas, " +"limitando assim quanto de largura de banda de rede e recursos do sistema são " +"consumidos." + +#. type: Title ==== +#: documentation/content/en/articles/hubs/_index.adoc:151 +#, no-wrap +msgid "Rsync (optional for FTP Fileset)" +msgstr "Rsync (opcional para o conjunto de arquivos do FTP)" + +#. type: Plain text +#: documentation/content/en/articles/hubs/_index.adoc:161 +msgid "" +"Rsync is often offered for access to the contents of the FTP area of " +"FreeBSD, so other mirror sites can use your system as their source. The " +"protocol is different from FTP in many ways. It is much more bandwidth " +"friendly, as only differences between files are transferred instead of whole " +"files when they change. Rsync does require a significant amount of memory " +"for each instance. The size depends on the size of the synced module in " +"terms of the number of directories and files. Rsync can use `rsh` and `ssh` " +"(now default) as a transport, or use its own protocol for stand-alone access " +"(this is the preferred method for public rsync servers). Authentication, " +"connection limits, and other restrictions may be applied. There is just one " +"software package available:" +msgstr "" +"O Rsync é frequentemente oferecido para acesso ao conteúdo da área FTP do " +"FreeBSD, para que outros sites espelho possam usar seu sistema como fonte. O " +"protocolo é diferente do FTP de muitas maneiras. É muito mais amigável para " +"a largura de banda, pois apenas as diferenças entre os arquivos são " +"transferidas em vez de arquivos inteiros quando são alterados. O Rsync " +"requer uma quantidade significativa de memória para cada instância. O " +"tamanho depende do tamanho do módulo sincronizado em termos do número de " +"diretórios e arquivos. O Rsync pode usar `rsh` e `ssh` (agora padrão) como " +"transporte ou usar seu próprio protocolo para acesso autônomo (este é o " +"método preferido para servidores Rsync públicos). A autenticação, limites de " +"conexão e outras restrições podem ser aplicadas. Há apenas um pacote de " +"software disponível:" + +#. type: Plain text +#: documentation/content/en/articles/hubs/_index.adoc:163 +msgid "package:net/rsync[]" +msgstr "package:net/rsync[]" + +#. type: Title ==== +#: documentation/content/en/articles/hubs/_index.adoc:165 +#, no-wrap +msgid "HTTP (required for Web Pages, Optional for FTP Fileset)" +msgstr "HTTP (necessário para as páginas web, opcional para o conjunto de arquivos do FTP)" + +#. type: Plain text +#: documentation/content/en/articles/hubs/_index.adoc:171 +msgid "" +"If you want to offer the FreeBSD web pages, you will need to install a web " +"server. You may optionally offer the FTP fileset via HTTP. The choice of " +"web server software is left up to the mirror administrator. Some of the " +"most popular choices are:" +msgstr "" +"Se você deseja oferecer as páginas web do FreeBSD, precisará instalar um " +"servidor web. Você pode opcionalmente oferecer o conjunto de arquivos FTP " +"via HTTP. A escolha do software do servidor web é deixada a critério do " +"administrador do espelho. Algumas das opções mais populares são:" + +#. type: Plain text +#: documentation/content/en/articles/hubs/_index.adoc:173 +msgid "" +"package:www/apache24[]: Apache is still one of the most widely deployed web " +"servers on the Internet. It is used extensively by the FreeBSD Project." +msgstr "" +"package:www/apache24[]: O Apache ainda é um dos servidores da Web mais " +"amplamente implantados na Internet. Ele é usado extensivamente pelo Projeto " +"FreeBSD." + +#. type: Plain text +#: documentation/content/en/articles/hubs/_index.adoc:174 +msgid "" +"package:www/boa[]: Boa is a single-tasking HTTP server. Unlike traditional " +"web servers, it does not fork for each incoming connection, nor does it fork " +"many copies of itself to handle multiple connections. Although, it should " +"provide considerably great performance for purely static content." +msgstr "" +"package:www/boa[]: O Boa é um servidor HTTP de single-task. Ao contrário dos " +"servidores web tradicionais, ele não faz um fork para cada conexão recebida, " +"nem faz muitas cópias de si mesmo para lidar com várias conexões. contudo, " +"ele deve fornecer um desempenho consideravelmente melhor para conteúdo " +"puramente estático." + +#. type: Plain text +#: documentation/content/en/articles/hubs/_index.adoc:175 +msgid "" +"package:www/cherokee[]: Cherokee is a very fast, flexible and easy to " +"configure web server. It supports the widespread technologies nowadays: " +"FastCGI, SCGI, PHP, CGI, SSL/TLS encrypted connections, vhosts, users " +"authentication, on the fly encoding and load balancing. It also generates " +"Apache compatible log files." +msgstr "" +"package:www/cherokee[]: O Cherokee é um servidor web muito rápido, flexível " +"e fácil de configurar. Ele suporta as tecnologias amplamente utilizadas hoje " +"em dia: FastCGI, SCGI, PHP, CGI, conexões criptografadas SSL/TLS, vhosts, " +"autenticação de usuários, codificação on the fly e balanceamento de carga. " +"Ele também gera arquivos de log compatíveis com o Apache." + +#. type: Plain text +#: documentation/content/en/articles/hubs/_index.adoc:176 +msgid "" +"package:www/lighttpd[]: lighttpd is a secure, fast, compliant and very " +"flexible web server which has been optimized for high-performance " +"environments. It has a very low memory footprint compared to other web " +"servers and takes care of cpu-load." +msgstr "" +"package:www/lighttpd[]: O lighttpd é um servidor web seguro, rápido, " +"compatível com os padrões e muito flexível o qual foi otimizado para " +"ambientes de alto desempenho. Tem um consumo de memória muito baixo em " +"comparação com outros servidores Web, bem como um baixo consumo de CPU." + +#. type: Plain text +#: documentation/content/en/articles/hubs/_index.adoc:177 +msgid "" +"package:www/nginx[]: nginx is a high performance edge web server with a low " +"memory footprint and key features to build a modern and efficient web " +"infrastructure. Features include a HTTP server, HTTP and mail reverse proxy, " +"caching, load balancing, compression, request throttling, connection " +"multiplexing and reuse, SSL offload and HTTP media streaming." +msgstr "" +"package:www/nginx[]: O nginx é um servidor web de borda de alta performance " +"com uma pegada de memória baixa e recursos importantes para construir uma " +"infraestrutura web moderna e eficiente. Os recursos incluem um servidor " +"HTTP, proxy reverso HTTP e de e-mail, cache, balanceamento de carga, " +"compressão, limitação de solicitações, multiplexação e reutilização de " +"conexões, offload SSL e streaming de mídia HTTP." + +#. type: Plain text +#: documentation/content/en/articles/hubs/_index.adoc:178 +msgid "" +"package:www/thttpd[]: If you are going to be serving a large amount of " +"static content you may find that using an application such as thttpd is more " +"efficient than others. It is also optimized for excellent performance on " +"FreeBSD." +msgstr "" +"package:www/thttpd[]: Se você vai servir uma grande quantidade de conteúdo " +"estático, pode descobrir que usar um aplicativo como o thttpd é mais " +"eficiente do que outros. Ele também é otimizado para ter um excelente " +"desempenho no FreeBSD." + +#. type: Title == +#: documentation/content/en/articles/hubs/_index.adoc:180 +#, no-wrap +msgid "How to Mirror FreeBSD" +msgstr "Como espelhar o FreeBSD" + +#. type: Plain text +#: documentation/content/en/articles/hubs/_index.adoc:184 +msgid "" +"Ok, now you know the requirements and how to offer the services, but not how " +"to get it. :-) This section explains how to actually mirror the various " +"parts of FreeBSD, what tools to use, and where to mirror from." +msgstr "" +"Ok, agora você conhece os requisitos e sabe como oferecer os serviços, mas " +"não sabe como obtê-los. :-) Esta seção explica como realmente espelhar as " +"várias partes do FreeBSD, quais ferramentas utilizar e de onde espelhar." + +#. type: Title === +#: documentation/content/en/articles/hubs/_index.adoc:186 +#, no-wrap +msgid "Mirroring the FTP Site" +msgstr "Espelhando o site FTP" + +#. type: Plain text +#: documentation/content/en/articles/hubs/_index.adoc:191 +msgid "" +"The FTP area is the largest amount of data that needs to be mirrored. It " +"includes the _distribution sets_ required for network installation, the " +"_branches_ which are actually snapshots of checked-out source trees, the " +"_ISO Images_ to write CD-ROMs with the installation distribution, a live " +"file system, and a snapshot of the ports tree. All of course for various " +"FreeBSD versions, and various architectures." +msgstr "" +"A área FTP possui a maior quantidade de dados que precisa ser espelhada. " +"Inclui os _conjuntos de distribuição_ necessários para instalação via rede, " +"os _branches_, que são na verdade snapshots dos diretórios de código fonte, " +"as _imagens ISO_ para gravar CD-ROMs com a distribuição de instalação, um " +"sistema de arquivos live (ao vivo) e um snapshot da árvore de ports. Tudo, é " +"claro, para várias versões do FreeBSD e várias arquiteturas." + +#. type: Plain text +#: documentation/content/en/articles/hubs/_index.adoc:197 +msgid "" +"The best way to mirror the FTP area is rsync. You can install the port " +"package:net/rsync[] and then use rsync to sync with your upstream host. " +"rsync is already mentioned in <>. Since rsync access is " +"not required, your preferred upstream site may not allow it. You may need " +"to hunt around a little bit to find a site that allows rsync access." +msgstr "" +"A melhor maneira de espelhar a área FTP é com o rsync. Você pode instalar o " +"pacote pelo port: net/rsync[] e, em seguida, usar o rsync para sincronizar " +"com seu host upstream. O rsync já foi mencionado em <>. " +"Como o acesso rsync não é obrigatório, seu site upstream preferido pode não " +"permiti-lo. Você pode precisar procurar um pouco para encontrar um site que " +"permita o acesso rsync." + +#. type: delimited block = 4 +#: documentation/content/en/articles/hubs/_index.adoc:202 +msgid "" +"Since the number of rsync clients will have a significant impact on the " +"server machine, most admins impose limitations on their server. For a " +"mirror, you should ask the site maintainer you are syncing from about their " +"policy, and maybe an exception for your host (since you are a mirror)." +msgstr "" +"Como o número de clientes rsync terá um impacto significativo no " +"processamento do servidor, a maioria dos administradores impõe limitações em " +"seu servidor. Para um espelho, você deve perguntar ao mantenedor do site de " +"onde está sincronizando sobre sua política e talvez pedir uma exceção para " +"seu host (já que você é um espelho)." + +#. type: Plain text +#: documentation/content/en/articles/hubs/_index.adoc:205 +msgid "A command line to mirror FreeBSD might look like:" +msgstr "" +"Um exemplo de linha de comando para espelhar o FreeBSD pode ser verificada " +"abaixo:" + +#. type: delimited block . 4 +#: documentation/content/en/articles/hubs/_index.adoc:209 +#, no-wrap +msgid "% rsync -vaHz --delete rsync://ftp4.de.FreeBSD.org/FreeBSD/ /pub/FreeBSD/\n" +msgstr "" +"% rsync -vaHz --delete rsync://ftp4.de.FreeBSD.org/FreeBSD/ /pub/FreeBSD/\n" + +#. type: Plain text +#: documentation/content/en/articles/hubs/_index.adoc:213 +msgid "" +"Consult the documentation for rsync, which is also available at http://rsync." +"samba.org/[http://rsync.samba.org/], about the various options to be used " +"with rsync. If you sync the whole module (unlike subdirectories), be aware " +"that the module-directory (here \"FreeBSD\") will not be created, so you " +"cannot omit the target directory. Also you might want to set up a script " +"framework that calls such a command via man:cron[8]." +msgstr "" +"Consulte a documentação do rsync, que também está disponível em http://rsync." +"samba.org/[http://rsync.samba.org/], sobre as várias opções a serem usadas " +"com o rsync. Se você sincronizar o módulo inteiro (ao contrário de " +"subdiretórios), esteja ciente de que o diretório do módulo (aqui \"FreeBSD\")" +" não será criado, portanto, você não pode omitir o diretório de destino. " +"Além disso, você pode querer configurar um framework de script que chame " +"esse comando via man:cron[8]." + +#. type: Title === +#: documentation/content/en/articles/hubs/_index.adoc:215 +#, no-wrap +msgid "Mirroring the WWW Pages" +msgstr "Espelhando as páginas WWW" + +#. type: delimited block = 4 +#: documentation/content/en/articles/hubs/_index.adoc:220 +msgid "" +"Since doc migration to Hugo/Asciidoctor on 2021-01-25, mirroring the website " +"with rsync no longer works." +msgstr "" +"Desde a migração da documentação para Hugo/Asciidoctor em 25/01/2021, a " *** 604 LINES SKIPPED *** From nobody Sun Apr 30 19:18:00 2023 X-Original-To: dev-commits-doc-all@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4Q8bhn1yv2z48Bvc for ; Sun, 30 Apr 2023 19:18:01 +0000 (UTC) (envelope-from git@FreeBSD.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Q8bhn1MBJz3wtg; Sun, 30 Apr 2023 19:18:01 +0000 (UTC) (envelope-from git@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1682882281; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=SC77asaXGkHkUr0jbrUyyO5v8NqVaE0doPP55tPltIk=; b=yI5CYuJPgelxWlV2ucujI61Li9G624bEfnUN2QPKZyiHRto/Wx1qkKEf96NOnMKCT0RNlG /z9nfLpn5Ik4c0j5hlpFGpJg+cAM4mu5QaVQJk3EWVvIHZ/cAE0CXDGiQbgzftq9GObDyv I3XA7sq+VJPqyjB4HMaqMSNNFiINh783goxqeTv6sSAKY7mEPLVQ6R3JKPwec0XxPQzicR pfwq0IiZfoIWadcgGhumUPxdZtxXLYENzfLN+qw+geQ/gcL30XxbuBI6hQy5M+OdHuqCQh OrFgXc4g/rOMVesKUb1JLHtkvAQZ2U2E4EQua404UcfRnNIECfRjbJOwnY2tbg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1682882281; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=SC77asaXGkHkUr0jbrUyyO5v8NqVaE0doPP55tPltIk=; b=SNgFcFpuYTHXHtGpIr5LHeevyUy9/xJg+NDNNk8hklYEGyCVI6rJ3dR3S5Z3HeIZj0NM7f E8z0LQB8WOKeOuaMOTC6pYfb39aPYeHcq6y7RiQOU9Wa7Hj7msv+ZA0f90B9dsPA+B2QP5 mlt+s/HGW2tkqB7ITB1VoHBUpYfWhA2C7kur8P7cXSazB2+JGuyJkpPnDwo9j7MJ2cpX9I f05A7sevfcUHn3nMVkFfobn2McXxPZHjHkNcTCE3/zG2uRV61ssoLoid67Faq98wWMsURk XxQ4ObpJ66+x6dn5y9lS85s7r6Zo3neepaNRW36ycaIc8oaN6QGT2ViqTJxkZw== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1682882281; a=rsa-sha256; cv=none; b=Fs0o8sR0MQ7H+8C+p517Ir/j5SI1VByPihldRb79daifKSWpTl5m4/Gp2iKe0a4dLlTBx/ Qd9BZrv2X/yN8jql+dGUingkbqQNxJOhkdSYm/ZFfFGXdzwD5QkYaHMbdwsi6TDq3QC1Xr eh3m/L6tRW/CLZ9rqdXs0kOFOnif6jpXs5tOLBYfte6zDXVlAnLUaZw4ngOfjCAdXXC5wt rWTftYCUqAXwwT1cdvPJg+16cWO9xgkcSg9nELKd6lue9StOo5uM2OiqEZk9D+fMjjmM25 udrErtud/82CvWjpX7y3iz7JNxGNv/Xast1gkiUVO/PJN9F5rgny5jNI05cz3Q== Received: from gitrepo.freebsd.org (gitrepo.freebsd.org [IPv6:2610:1c1:1:6068::e6a:5]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 4Q8bhn0JGRzZgh; Sun, 30 Apr 2023 19:18:01 +0000 (UTC) (envelope-from git@FreeBSD.org) Received: from gitrepo.freebsd.org ([127.0.1.44]) by gitrepo.freebsd.org (8.16.1/8.16.1) with ESMTP id 33UJI0OI094091; Sun, 30 Apr 2023 19:18:00 GMT (envelope-from git@gitrepo.freebsd.org) Received: (from git@localhost) by gitrepo.freebsd.org (8.16.1/8.16.1/Submit) id 33UJI0OS094090; Sun, 30 Apr 2023 19:18:00 GMT (envelope-from git) Date: Sun, 30 Apr 2023 19:18:00 GMT Message-Id: <202304301918.33UJI0OS094090@gitrepo.freebsd.org> To: doc-committers@FreeBSD.org, dev-commits-doc-all@FreeBSD.org From: Vladimir Druzenko Subject: git: ecc5e5585b - main - Add records about new ports committer (vvd) List-Id: Commit messages for all branches of the doc repository List-Archive: https://lists.freebsd.org/archives/dev-commits-doc-all List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-dev-commits-doc-all@freebsd.org X-BeenThere: dev-commits-doc-all@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Git-Committer: vvd X-Git-Repository: doc X-Git-Refname: refs/heads/main X-Git-Reftype: branch X-Git-Commit: ecc5e5585bc1b277d789869f1eac773af8751523 Auto-Submitted: auto-generated X-ThisMailContainsUnwantedMimeParts: N The branch main has been updated by vvd: URL: https://cgit.FreeBSD.org/doc/commit/?id=ecc5e5585bc1b277d789869f1eac773af8751523 commit ecc5e5585bc1b277d789869f1eac773af8751523 Author: Vladimir Druzenko AuthorDate: 2023-04-30 19:16:32 +0000 Commit: Vladimir Druzenko CommitDate: 2023-04-30 19:16:32 +0000 Add records about new ports committer (vvd) New author entry for Vladimir Druzenko together with the news item and PGP key added. List of Developers and Contributors updated as well to follow steps 1-4 of the Committers Guide. Reported by: vvd Approved by: arrowd (mentor) Differential Revision: https://reviews.freebsd.org/D39858 --- .../content/en/articles/pgpkeys/_index.adoc | 3 +++ documentation/static/pgpkeys/vvd.key | 27 ++++++++++++++++++++++ shared/authors.adoc | 4 ++++ shared/contrib-committers.adoc | 1 + website/data/en/news/news.toml | 4 ++++ 5 files changed, 39 insertions(+) diff --git a/documentation/content/en/articles/pgpkeys/_index.adoc b/documentation/content/en/articles/pgpkeys/_index.adoc index 7ebedcf626..3575b68e60 100644 --- a/documentation/content/en/articles/pgpkeys/_index.adoc +++ b/documentation/content/en/articles/pgpkeys/_index.adoc @@ -1455,6 +1455,9 @@ include::{include-path}meta.key[] === `{rnagy}` include::{include-path}rnagy.key[] +=== `{vvd}` +include::{include-path}vvd.key[] + [[pgpkeys-other]] == Other Cluster Account Holders diff --git a/documentation/static/pgpkeys/vvd.key b/documentation/static/pgpkeys/vvd.key new file mode 100644 index 0000000000..a1294bccd6 --- /dev/null +++ b/documentation/static/pgpkeys/vvd.key @@ -0,0 +1,27 @@ +// sh addkey.sh vvd 8006FAABBF942F73 ; + +[.literal-block-margin] +.... +pub ed25519/8006FAABBF942F73 2023-04-27 [SC] [expires: 2026-04-26] + Key fingerprint = 0956 DE50 9EAD 9D7E 4E61 8CC2 8006 FAAB BF94 2F73 +uid Vladimir Druzenko +sub cv25519/D9E8405F72978A9E 2023-04-27 [E] [expires: 2026-04-26] + +.... + +[.literal-block-margin] +.... +-----BEGIN PGP PUBLIC KEY BLOCK----- + +xjMEZEmcEhYJKwYBBAHaRw8BAQdAzzVRU/u5Oe4kUEFSvaiRoAPwsXMi4uBnfKqF +TOIxjaDNI1ZsYWRpbWlyIERydXplbmtvIDx2dmRAZnJlZWJzZC5vcmc+wo8EExYI +ADcWIQQJVt5Qnq2dfk5hjMKABvqrv5QvcwUCZEmcEgUJBaOagAIbAwQLCQgHBRUI +CQoLBRYCAwEAAAoJEIAG+qu/lC9z/qcBALviJppCfpN8fLj5HfnQ75ARS/RvOL+b +PHB422uv9PFOAP982mg4uqoYr1BvSVqmrtB7/oxkqReIeieBIkyBTM97As44BGRJ +nBMSCisGAQQBl1UBBQEBB0D41GJgPsXUyWQckRf725z8CsGADMjlIpJbVhWUQLi4 +fwMBCAfCfgQYFggAJhYhBAlW3lCerZ1+TmGMwoAG+qu/lC9zBQJkSZwTBQkFo5qA +AhsMAAoJEIAG+qu/lC9z4bgA/jGNXk0cGGKii1lXk55Gwh2EQhC4pLxQe/36TZiR +29IBAP40fSUJOJ41IS0d8k6d5DQ0E9BJuRf+1S5AzsAUz0rmBQ== +=x+2b +-----END PGP PUBLIC KEY BLOCK----- +.... diff --git a/shared/authors.adoc b/shared/authors.adoc index b60515edc2..7496a052c9 100644 --- a/shared/authors.adoc +++ b/shared/authors.adoc @@ -3492,6 +3492,10 @@ :vsevolod-email: vsevolod@FreeBSD.org :vsevolod: {vsevolod-name} <{vsevolod-email}> +:vvd-name: Vladimir Druzenko +:vvd-email: vvd@FreeBSD.org +:vvd: {vvd-name} <{vvd-email}> + :vwe-name: Volker Werth :vwe-email: vwe@FreeBSD.org :vwe: {vwe-name} <{vwe-email}> diff --git a/shared/contrib-committers.adoc b/shared/contrib-committers.adoc index d83e62958b..c9418a5904 100644 --- a/shared/contrib-committers.adoc +++ b/shared/contrib-committers.adoc @@ -77,6 +77,7 @@ * {donner} * {bdrewery} * {gad} +* {vvd} * {kd} * {ale} * {deischen} diff --git a/website/data/en/news/news.toml b/website/data/en/news/news.toml index 0cc712b142..42fa2c535e 100644 --- a/website/data/en/news/news.toml +++ b/website/data/en/news/news.toml @@ -66,6 +66,10 @@ description = "The first BETA build for the FreeBSD 13.2 release cycle is now av date= "2023-02-09" description = "New committer: Robert Nagy (ports)" +[[news]] +date= "2023-02-02" +description = "New committer: Vladimir Druzenko (ports)" + [[news]] date = "2023-02-02" description = "New committer: Robert Clausecker (ports)" From nobody Mon May 1 14:03:14 2023 X-Original-To: dev-commits-doc-all@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4Q94g65dP8z48ZtT for ; Mon, 1 May 2023 14:03:14 +0000 (UTC) (envelope-from git@FreeBSD.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Q94g653j5z3N6m; Mon, 1 May 2023 14:03:14 +0000 (UTC) (envelope-from git@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1682949794; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=z85ScNQPsrLqdRsr+F5NZpUrcjKecIPAcrkDqnv/QeI=; b=w8e75s68DwSOnOvdfhgf5nrfnTCs5Obw9psrndgh2v+uhLr6v5dvz9oxtpfqcwJtUKpHOf lwFpMDA1q9+b1Jq8l4VDKhrUOiVWS3OSfPZg7HAaBuLYMo8OvucPGkVV3I7vfbaHcvf2uY ZHy8zjQ8ah07PyHakCVYhxwnwQI5ssdJ3khFaxgIzKpnSxm3HZC75G5hh8dRB16mDVscGo ivqUb/KdDphkK7OQzT1MCEHJyFLesHNjp6zo9VArKSJQOTeLpOpUoG6jxqI+YHEcRMGQkU Z9Ubn6rAkhAXdb6PnR/NPmQn5iufT79y5DFdcCljFi1DbJfSkYkEZHMELI2ybA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1682949794; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=z85ScNQPsrLqdRsr+F5NZpUrcjKecIPAcrkDqnv/QeI=; b=NyLzYU8ZfEtZyj1+VBTmm9VAXMHSZIQJMPP9XX47DS4izeVEUzU5pjFuSUQc5k/zRBFwT1 3nUWTLCaKM66g9RyVGjLxxXF1zyv8xKO4hG+BMmhwlFwUmMRx8EHiLn7TJ/KiBfHCTkZR4 Gam86FDMueXOepNlSu3g7B44eiSSfdoDJTsM7u7RFRK3ULe8QVFkFILwUl8kZQ62IwVwjA mDwTjmE4N/Wz7JzWsAJD3YXJY2AnKLYKwmsAF6+xVsT7S2Ij2yd0tqn9+nkE1s+SYpYm+3 79y+nlntnsVHanP3GajNenNxU03sTNnuOmmdj40kIEbtGbO/RWPu884xac+faQ== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1682949794; a=rsa-sha256; cv=none; b=QBSA2ljBLiTQfFbVCX222SKu6J4UB1ul95DF++u3Ie+E6GspisuGIsXv+O60sNQ+gvTrAO UTmiu/j9c9izVU1ZOlI17FwC6ZZP0zliET3J6gMXAWosBP5WKpLbte/QjvnncOlxZh72C0 tBsCbw2dNf86Qe9nkRfmTnATY4W2tcKkJ8zbmsaT+hUTyDxEjYhLQ0TA6X7FFaUJbEZALR dK0C/TK9Wu6KK3X/3gtk8zjC5FzMwjBW4vpjZDtOQwbV08ZrsftQ3hicYaT0PmpM19vx/q fKF8/JGX5KFxAeSO/6SeDX6qtZjl+4x1W/2wR9V2CFfc50U6L7UeFEpGfXGE1A== Received: from gitrepo.freebsd.org (gitrepo.freebsd.org [IPv6:2610:1c1:1:6068::e6a:5]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 4Q94g646z0z16fR; Mon, 1 May 2023 14:03:14 +0000 (UTC) (envelope-from git@FreeBSD.org) Received: from gitrepo.freebsd.org ([127.0.1.44]) by gitrepo.freebsd.org (8.16.1/8.16.1) with ESMTP id 341E3EWR056462; Mon, 1 May 2023 14:03:14 GMT (envelope-from git@gitrepo.freebsd.org) Received: (from git@localhost) by gitrepo.freebsd.org (8.16.1/8.16.1/Submit) id 341E3EQo056461; Mon, 1 May 2023 14:03:14 GMT (envelope-from git) Date: Mon, 1 May 2023 14:03:14 GMT Message-Id: <202305011403.341E3EQo056461@gitrepo.freebsd.org> To: doc-committers@FreeBSD.org, dev-commits-doc-all@FreeBSD.org From: "Danilo G. Baio" Subject: git: 84a3c57be8 - main - ko/articles/bsdl-gpl: Sync with en List-Id: Commit messages for all branches of the doc repository List-Archive: https://lists.freebsd.org/archives/dev-commits-doc-all List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-dev-commits-doc-all@freebsd.org X-BeenThere: dev-commits-doc-all@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Git-Committer: dbaio X-Git-Repository: doc X-Git-Refname: refs/heads/main X-Git-Reftype: branch X-Git-Commit: 84a3c57be850f3760443f846a7328dae4785b624 Auto-Submitted: auto-generated X-ThisMailContainsUnwantedMimeParts: N The branch main has been updated by dbaio: URL: https://cgit.FreeBSD.org/doc/commit/?id=84a3c57be850f3760443f846a7328dae4785b624 commit 84a3c57be850f3760443f846a7328dae4785b624 Author: Kyung-tak, Yoo AuthorDate: 2023-05-01 14:00:29 +0000 Commit: Danilo G. Baio CommitDate: 2023-05-01 14:02:33 +0000 ko/articles/bsdl-gpl: Sync with en Obtained from: https://translate-dev.freebsd.org/ Pull Request: https://github.com/freebsd/freebsd-doc/pull/180 --- .../content/ko/articles/bsdl-gpl/_index.adoc | 171 ++-- .../content/ko/articles/bsdl-gpl/_index.po | 1078 ++++++++++++++++++++ 2 files changed, 1162 insertions(+), 87 deletions(-) diff --git a/documentation/content/ko/articles/bsdl-gpl/_index.adoc b/documentation/content/ko/articles/bsdl-gpl/_index.adoc index 22f21f229f..514ea4c42f 100644 --- a/documentation/content/ko/articles/bsdl-gpl/_index.adoc +++ b/documentation/content/ko/articles/bsdl-gpl/_index.adoc @@ -1,12 +1,15 @@ --- -title: 오픈 소스 프로젝트에 BSD 형식의 라이선스를 사용해야 하는 이유 authors: - - author: Bruce Montague + - + author: 'Bruce Montague' email: brucem@alumni.cse.ucsc.edu +description: '오픈소스 프로젝트에 BSD 스타일 라이선스를 사용해야 하는 이유' +tags: ["bsdl", "gpl", "FreeBSD License"] +title: '오픈소스 프로젝트에 BSD 스타일 라이선스를 사용해야 하는 이유' trademarks: ["freebsd", "intel", "general"] --- -= 오픈 소스 프로젝트에 BSD 형식의 라이선스를 사용해야 하는 이유 += 오픈소스 프로젝트에 BSD 스타일 라이선스를 사용해야 하는 이유 :doctype: article :toc: macro :toclevels: 1 @@ -42,167 +45,161 @@ endif::[] toc::[] [[intro]] -== 개요 +== 소개 -이 문서는 소프트웨어와 데이터에 BSD 형식의 라이선스를 사용해야 하는 이유를 설명합니다; 구체적으로 이 문서는 GPL 대신 BSD 형식의 라이선스를 사용할 것을 권장합니다. 이 문서는 또한 BSD와 GPL 오픈 소스 라이선스에 대한 소개 및 간단한 요약이기도 합니다. +이 문서는 소프트웨어와 데이터에 BSD 스타일 라이선스를 사용하는 사례를 제시하며, 특히 GPL 대신 BSD 스타일 라이선스를 사용할 것을 권장합니다. 이 문서는 BSD와 GPL 오픈 소스 라이선스 소개 및 요약으로 생각하셔도 됩니다. [[history]] -== 오픈 소스의 아주 간략한 역사 +== 아주 간략한 오픈소스 역사 -"오픈 소스"라는 용어가 사용되기 오래 전에, 소프트웨어는 프로그래머들의 자발적인 공동체에 의해 개발되고 자유롭게 주고받아졌습니다. 1950년대 초반을 시작으로, http://www.share.org[SHARE]와 http://www.decus.org[DECUS]와 같은 단체들은 컴퓨터 하드웨어 회사들이 자사의 제품에 동봉한 소프트웨어의 상당수를 개발했습니다. 그 당시 컴퓨터 회사들은 주로 하드웨어 사업을 하고 있었습니다; 소프트웨어의 비용을 낮추고 더 많은 프로그램들을 사용 가능하도록 제공하는 것은 곧 하드웨어 회사들의 경쟁력이 되었습니다. +“오픈 소스”라는 용어가 사용되기 훨씬 전부터 소프트웨어는 프로그래머들의 느슨한 연합에 의해 개발되고 자유롭게 교환되었습니다. 1950년대 초부터 http://www.share.org[SHARE] 및 http://www.decus.org[DECUS]와 같은 조직이 컴퓨터 하드웨어 회사가 하드웨어 제품에 번들로 제공하는 소프트웨어의 대부분을 개발했습니다. 당시 컴퓨터 회사들은 하드웨어를 주축으로 사업을 하고 있었기 때문에 소프트웨어 비용을 절감하고 더 많은 프로그램을 사용할 수 있게 하면 컴퓨터 회사의 경쟁력이 높아졌습니다. -이러한 방침은 1960년대에 바뀌었습니다. 1965년에 ADR은 하드웨어 제조사와는 독립적으로 라이선스된 최초의 소프트웨어 제품을 개발했습니다. ADR은 IBM의 고객들에 의해 개발된 무료 IBM 패키지와 경쟁하고 있었습니다. ADR은 1968년에 그들의 소프트웨어에 대한 특허를 출원했습니다. 그들의 프로그램이 (불법으로) 공유되는 것을 막기 위해, 그들은 그들의 프로그램을 (사용하기 위해서는 비용을 지불해야 하는) 임대 형식의 장비에서만 제공했습니다. 그럼으로써 ADR은 소프트웨어에 대한 소유권을 얻었고, 소프트웨어의 재판매와 재사용을 하지 못하도록 통제할 수 있었습니다. +이 모델은 1960년대에 바뀌었습니다. 1965년 ADR은 하드웨어 회사로부터 독립하여 최초의 라이선스 소프트웨어 제품을 개발했습니다. ADR은 원래 IBM 고객이 개발한 무료 IBM 패키지와 경쟁하고 있었습니다. ADR은 1968년 소프트웨어 특허를 획득했습니다. 프로그램의 공유를 막기 위해 제품 수명 기간 동안 요금을 나눠내는 장비 리스 방식으로 제품을 제공했습니다. 따라서 ADR은 소유권을 유지하고 재판매 및 재사용을 통제할 수 있었습니다. -1969년에 미국 법무부는 IBM이 그들의 하드웨어에 무료 소프트웨어를 동봉하여 시장을 독점하려 한 것에 대해 벌금을 부과했습니다. 이 소송의 결과로, IBM은 더 이상 그들의 제품에 소프트웨어를 동봉하지 않았습니다; 즉, 소프트웨어는 하드웨어와는 독립적인 제품이 되었습니다. +1969년 미국 법무부는 IBM이 무료 소프트웨어를 IBM 하드웨어에 번들로 제공함으로써 비즈니스를 파괴했다는 혐의로 IBM을 기소했습니다. 이 소송의 결과로 IBM은 소프트웨어를 번들에서 분리하였고, 소프트웨어가 하드웨어와 분리된 독립적인 제품이 되었습니다. -1968년에 Informatics는 최초로 상용 killer-app을 발표하고 소프트웨어 제품, 소프트웨어 회사, 그리고 많은 이윤에 대한 개념을 빠르게 정착시켜 나갔습니다. Informatics는 현재 컴퓨터 산업의 표준과도 같은 영구 라이선스를 개발했습니다. 이 라이선스는 소프트웨어의 소유에 대한 권리가 소비자에게 주어지지 않는다는 특징이 있습니다. +1968년 인포매틱스(Informatics)는 최초의 상용 킬러 앱을 출시하여 소프트웨어 제품, 소프트웨어 회사, 매우 높은 수익률이라는 개념을 빠르게 정립했습니다. 인포매틱스는 현재 컴퓨터 업계에서 표준이 된 영구 라이선스를 개발했는데, 이 라이선스는 소유권이 고객에게 이전되지 않습니다. [[unix-license]] -== BSD 라이선스의 관점에서 바라본 유닉스 +== BSD 라이선스 관점에서 본 유닉스 -원본 유닉스 구현을 소유하고 있던 AT&T는 반독점법에 의해 공식적으로 규제를 받고 있었습니다; 그 회사는 합법적으로 소프트웨어 제품을 판매할 수 없었습니다. 그러나 학술 기관에 저장 매체의 비용만을 받고 소프트웨어를 제공하는 것은 가능했습니다. +최초의 유닉스 구현을 소유한 AT&T는 미국의 반독점법에 묶여 공공 규제를 받는 독점기업이었기 때문에 법적으로 소프트웨어 시장에 제품을 판매할 수 없었습니다. 하지만 학술 기관에는 미디어 가격(순수한 패키지 가격)을 받고 제공할 수 있었습니다. -OS conference에서 유닉스를 사용 가능하다고 발표한 이후에, 대학교들은 그것을 빠르게 채택했습니다. 유닉스는 대단히 저렴한 16비트 컴퓨터인 PDP-11에서 작동했고, 시스템 프로그래밍에 명백하게 유리한 고급 언어로 작성되어 있었습니다. 이는 대단히 유용한 특징이었습니다. DEC PDP-11은 소비자들이 그들만의 운영체제를 작성(그 당시에는 꽤나 보편적인 일이었습니다)하기 쉽도록 하드웨어 인터페이스를 공개하고 있었습니다. DEC의 창립자인 Ken Olsen이 했던 말은 유명합니다, "당신이 좋은 하드웨어를 가지고 있다면 소프트웨어는 하늘이 내려 준다". +한 OS 컨퍼런스에서 유닉스를 공적으로 사용할 수 있다는 사실이 알려지면서 많은 대학들은 빠르게 유닉스를 도입했습니다. 유닉스가 매우 저렴한 16비트 컴퓨터인 PDP-11에서 실행되고 시스템 프로그래밍에 매우 적합한 고급 언어로 코딩되어 있었다는 점이 큰 도움이 되었습니다. DEC PDP-11은 고객이 자체 OS를 쉽게 작성할 수 있도록 설계된 개방형 하드웨어 인터페이스를 갖추고 있었는데, 당시에는 이러한 인터페이스가 일반적이었습니다. “좋은 하드웨어가 있으면 소프트웨어는 하늘에서 내려온다”는 DEC 창립자 켄 올슨(Ken Olsen)의 유명한 명언이 있습니다. -유닉스의 개발자인 Ken Thompson은 1975년에 그의 모교인 캘리포니아 버클리 대학교(UCB)로 돌아왔고, 커널을 한줄씩 가르쳤습니다. 이는 궁극적으로 BSD(Berkeley Standard Distribution)라는 시스템으로 발전했습니다. UCB는 유닉스를 32비트로 변환시켰고, 가상 메모리와 TCP/IP 스택(인터넷의 핵심 기술)을 구현했습니다. UCB는 BSD를 "BSD 라이선스"라고 알려지게 된 규정에 따라 저장 매체의 비용만 받고 누구에게나 제공했습니다. 소비자들은 AT&T에서 유닉스를 구입했고 UCB에서 BSD 테이프(당시의 저장 매체)를 주문했습니다. +유닉스의 창시자 켄 톰슨(Ken Thompson)은 1975년 모교인 캘리포니아 버클리 대학교(UCB)로 돌아와 커널을 한 줄 한 줄 가르쳤습니다. 그 결과 BSD(버클리 표준 배포판)로 알려진 진화하는 시스템이 탄생했습니다. UCB는 유닉스를 32비트로 변환하고, 가상 메모리를 추가하고, 인터넷의 기본이 되는 TCP/IP 스택 버전을 구현했습니다. UCB는 “BSD 라이선스”라는 이름으로 미디어 비용으로 BSD를 사용할 수 있게 했습니다. 과거에 AT&T에서 유닉스를 구입한 고객들은 이제 UCB에서 BSD 테이프를 주문하게 되었습니다. -1980년대 중반에 정부의 ATT에 대한 독점 소송은 ATT가 회사의 사업부를 분할하는 것으로 끝났습니다. ATT는 여전히 유닉스를 소유하고 있었고 이제는 판매도 할 수 있었습니다. ATT는 공격적인 라이선스 정책을 추진했으며 오늘날의 주요한 상용 유닉스들은 ATT 기반이 되었습니다. +1980년대 중반, AT&T에 대한 정부의 반독점 소송으로 인해 AT&T가 해체되었습니다. AT&T는 여전히 유닉스를 소유하고 있었으며 이제 이를 판매할 수 있게 되었습니다. AT&T는 공격적인 라이선스 확보에 나섰고, 당시 대부분의 상용 유닉스는 AT&T에서 파생된 제품이 되었습니다. -1990년대 초반에 ATT는 BSD에 관련된 라이선스의 위반으로 UCB에 소송을 제기했습니다. UCB는 ATT가 자사의 제품에 BSD의 향상된 기능을 아무런 승인이나 대가 지불 없이 포함시킨 것을 발견했고, 주로 ATT와 UCB 사이의 기나긴 소송 사건이 잇따라 발생했습니다. 이 기간 동안 UCB의 프로그래머들 중 일부는 BSD에 포함된 ATT 코드를 모두 다시 작성하는 작업에 착수했습니다. 이 작업의 결과로 bsd 4.4-lite라고 불리는 시스템이 만들어졌습니다 (이것은 완전한 시스템이 아니었기 때문에 lite라는 표현이 사용되었습니다; 이는 6개의 핵심적인 ATT 파일이 빠졌기 때문입니다). +1990년대 초, AT&T는 BSD와 관련된 라이선스 위반으로 UCB를 고소했습니다. 이 과정에서 UCB는 AT&T가 BSD로 인한 많은 개선 사항을 승인이나 대가 없이 AT&T의 제품에 통합했다는 사실을 발견했고, AT&T와 UCB 간의 오랜 법정 소송이 이어졌습니다. 이 기간 동안 일부 UCB 프로그래머들은 BSD와 관련된 모든 AT&T 코드를 다시 작성하는 프로젝트에 착수했습니다. 이 프로젝트는 BSD 4.4-lite라는 시스템을 탄생시켰습니다(라이트라고 명명한 것은 6개의 주요 AT&T 파일이 부족해 완전한 시스템이 아니었기 때문입니다). -얼마 후에, Dr. Dobbs의 잡지에 BSD 파생의 386 PC 버전 유닉스를 설명하는 긴 글이 수록되었습니다. 이것은 4.4 lite에 결손된 6개의 파일들을 BSD 라이선스의 것으로 대체한 버전이었습니다. 386BSD라고 이름지어진 이 시스템은 전 UCB 프로그래머인 William Jolitz에 의한 것이었습니다. 이것은 오늘날 사용되는 PC 호환 BSD들의 기본적인 바탕이 되었습니다. +조금 후에 닥터 돕스(Dr. Dobbs) 잡지에 실린 긴 기사 시리즈에서는 누락된 6개의 4.4 라이트 파일에 대한 BSD 라이선스 대체 파일과 함께 BSD 파생 386 PC 버전의 유닉스에 대해 설명했습니다. 386BSD로 명명된 이 시스템은 전직 UCB 프로그래머 윌리엄 졸리츠(William Jolitz)가 만든 것입니다. 이 시스템은 현재 사용 중인 모든 PC BSD의 기반이 되었습니다. -1990년대 중반에, Novell이 ATT의 유닉스에 대한 권리를 인수했고 (그 당시 비밀이었던) 협정에 의해 소송은 종료되었습니다. UCB는 곧 BSD에 대한 지원을 종료했습니다. +1990년대 중반, 노벨(Novell)은 AT&T의 유닉스 권리를 인수했고, 소송을 종료하기로 (당시엔 비밀리에) 합의가 이루어졌습니다. UCB는 곧 BSD에 대한 지원을 종료했습니다. [[current-bsdl]] -== FreeBSD 라이선스와 BSD 라이선스의 현재 상황 +== FreeBSD의 현황과 BSD 라이선스 -지난 몇 년동안 FreeBSD에 적용되어 온 소위 http://www.opensource.org/licenses/bsd-license.php[new BSD license]는 여러분이 프로그램 또는 그 소스를 가지고 무엇이든지 해도 되지만, 아무런 보증도 되지 않으며 저작자 중 아무도 책임지지 않음(즉, 여러분은 아무도 고소할 수 없습니다)을 나타내는 사실상 하나의 선언입니다. 이 new BSD license는 제품의 상용화를 장려하고 있습니다. 어떤 BSD 코드라도 여러분의 코드의 사용 가능성 또는 여러분의 미래의 행동에 아무런 제약을 받지 않고 판매되거나 상용 제품에 포함될 수 있습니다. +지난 몇 년 동안 FreeBSD에 적용된 소위 http://www.opensource.org/licenses/bsd-license.php[new BSD license]는 사실상 프로그램이나 그 소스로 무엇이든 할 수 있지만, 그 어떤 보증도 없고, 어떤 저작자도 책임을 지지 않는다는 선언입니다(기본적으로 누구에게도 소송을 제기할 수 없습니다). 이 새로운 BSD 라이선스는 제품 상용화를 장려하기 위한 것입니다. 모든 BSD 코드는 코드의 가용성이나 향후 행위에 대한 제한 없이 판매되거나 독점 제품에 포함될 수 있습니다. -new BSD 라이선스를 "공공재"와 혼동하지 마십시오. 공공재에 속한 대상 역시 모두가 무료로 사용할 수 있지만, 그것은 소유자가 없습니다. +새로운 BSD 라이선스를 “퍼블릭 도메인”과 혼동하지 마세요. 퍼블릭 도메인의 항목도 누구나 무료로 사용할 수 있지만 소유자가 없습니다. [[origins-gpl]] -== GPL의 기원 +== GPL의 유래 -1980년대 말과 1990년대 초에 유닉스의 미래가 혼란스러웠을 동안, 또 다른 주요 라이선스인 GPL이 개발의 결실을 맺었습니다. +1980년대 말과 1990년대 초, 유닉스의 미래가 매우 혼란스러웠을 때 라이선스를 중요하게 고려한 GPL이 나타났습니다. -Emacs의 개발자인 Richard Stallman이 MIT의 스태프 멤버였을 때, 그의 연구실은 시스템을 직접 개발하는 방식에서 상용 제품을 사용하는 방식으로 바꾸었습니다. Stallman은 그가 합법적으로 시스템을 개선할 수 없다는 사실을 알고 화가 났습니다. (Stallman의 동료들 대다수는 MIT에서 개발하고 라이선스한 소프트웨어를 기반으로 하는 두 회사를 창업하기 위해 떠났습니다; 이 소프트웨어의 소스 코드에 대한 관점에서 의견의 불일치가 있었던 것으로 보입니다). Stallman은 상용 소프트웨어 라이선스에 대한 대안을 마련했고 이를 GPL, "GNU Public License"라고 이름지었습니다. 그는 또한 http://www.fsf.org[Free Software Foundation] (FSF)라고 불리는 비영리 단체를 만들었는데, 이는 상용 라이선스에 종속적이지 않으면서 관련 소프트웨어를 포함하는 완전한 운영 체제 개발을 목 로 했습니다. 이 시스템은 "GNU is Not Unix"라는 뜻의 GNU라고 불렸습니다. +Emacs의 개발자인 리처드 스톨먼(Richard Stallman)은 MIT에서 연구실을 자체 개발 시스템에서 독점 시스템으로 전환할 당시 직원으로 근무하고 있었습니다. 스톨만은 시스템에 사소한 개선 사항을 법적으로 추가할 수 없다는 사실을 알게 되자 화가 났습니다. (스톨만의 동료들 중 다수는 MIT에서 개발하고 MIT가 라이선스를 부여한 소프트웨어를 기반으로 한 두 개의 회사를 설립하기 위해 회사를 떠났는데, 이 소프트웨어의 소스 코드에 대한 접근 권한에 대해 이견이 있었던 것으로 보입니다). 스톨만은 상용 소프트웨어 라이선스에 대한 대안을 고안해냈고 이를 GPL, 즉 “GNU 공중 라이선스”라고 불렀습니다. 또한 그는 비영리 재단인 http://www.fsf.org[자유 소프트웨어 재단](FSF)을 설립하여 모든 관련 소프트웨어를 포함한 전체 운영 체제를 독점 라이선스의 적 용을 받지 않는 것으로 개발하고자 했습니다. 이 시스템은 “GNU는 유닉스가 아니다”라는 뜻에서 GNU라고 불렀습니다. -GPL은 표준적인 상용 라이선스의 정반대 역할을 하도록 디자인되었습니다. 이 관점에서, GPL 프로그램에 어떤 수정이라도 가하면 (사용자에게 소스 코드를 제공하도록 요구하는 방식으로) GPL 커뮤니티에 환원해야 하고 GPL 코드를 사용하거나 링크한 프로그램은 모두 GPL 라이선스를 사용해야 합니다. GPL은 소프트웨어가 상용 제품이 되는 것을 막도록 의도하고 있습니다. GPL 본문의 마지막 문단은 다음과 같이 말하고 있습니다: +GPL은 표준 독점 라이선스와 반대되는 개념으로 설계되었습니다. 이를 위해 GPL 프로그램을 수정할 경우 해당 프로그램의 소스를 사용자가 원하면 접근할 수 있도록 GPL 커뮤니티에 환원해야 했고, GPL 코드를 사용하거나 링크하는 모든 프로그램은 GPL에 따라 사용해야 했습니다. GPL은 소프트웨어가 독점적인 소유물이 되는 것을 막기 위한 것입니다. GPL의 마지막 단락에 명시되어 있듯이: -"General Public License는 여러분의 프로그램을 상용 프로그램에 포함시키는 것을 허용하지 않습니다."[1] +“본 일반 공중 사용 허가서는 귀하의 프로그램을 독점 프로그램에 통합하는 것을 허용하지 않습니다.”<> -http://www.opensource.org/licenses/gpl-license.php[GPL]는 복잡한 라이선스이기 때문에 GPL을 사용하는 데에는 몇 가지 원칙이 있습니다: +http://www.opensource.org/licenses/gpl-license.php[GPL]은 복잡한 라이선스이므로 GPL을 사용할 때 지켜야 할 몇 가지 규칙이 있습니다: -* 여러분은 소프트웨어를 배포하고, 지원하고, 관련된 문서에 대해 필요한 요금을 원하는 만큼 책정할 수 있지만, 소프트웨어 그 자체를 판매할 수는 없습니다. -* 프로그램을 컴파일하는 데 GPL 코드가 필요하다면, 그 프로그램은 GPL을 따라야 합니다. GPL 라이브러리에 정적으로 링크된 프로그램도 GPL을 따라야 합니다. -* GPL은 GPL 소프트웨어 및 연관된 모든 개발품을 누구든지 자유롭게 사용할 수 있도록 라이선스할 것을 요구하고 있습니다. -* 단순히 소프트웨어들을 한데 모아 놓는 것은, 예를 들어 여러 프로그램들이 하나의 디스크에 저장되는 경우, GPL 프로그램을 비 GPL 프로그램에 포함시키는 것으로 간주되지 않습니다. -* 프로그램의 출력 결과는 파생 작업으로 간주되지 않습니다. 이는 gcc 컴파일러를 법적 문제 없이 상용 환경에 사용할 수 있도록 해 줍니다. -* 리눅스 커널이 GPL이기 때문에, 리눅스 커널에 정적으로 링크된 코드는 모두 GPL을 따라야 합니다. 동적으로 링크되고 로드할 수 있는 커널 모듈을 통해 이 요구사항을 우회할 수 있습니다. 이 허용은 회사로 하여금 바이너리 드라이버를 배포할 수 있도록 해 주지만, 특정한 버전의 리눅스 커널에서만 동작하게 된다는 단점도 있습니다. +* 소프트웨어 배포, 지원 또는 문서화 비용은 얼마든지 청구할 수 있지만 소프트웨어 자체는 판매할 수 없습니다. +* 일반적인 원칙상, 프로그램을 컴파일하는 데 GPL 소스가 필요한 경우 해당 프로그램은 반드시 GPL에 따라야 합니다. 또한 GPL 라이브러리에 정적으로 링크하려면 프로그램은 GPL을 따라야 합니다. +* GPL에 따르면 GPL 소프트웨어와 관련된 모든 특허는 모든 사람이 자유롭게 사용할 수 있도록 라이선스가 부여되어야 합니다. +* 여러 프로그램을 하나의 디스크에 넣을 때처럼 단순히 소프트웨어를 한데 모으는 것은 GPL이 아닌 프로그램에 GPL이 적용된 프로그램을 포함하는 것으로 간주하지 않습니다. +* 프로그램의 결과물은 2차적 저작물로 간주되지 않습니다. 따라서 gcc 컴파일러는 법적 문제 없이 상업적 환경에서 사용할 수 있습니다. +* Linux 커널은 GPL에 따라 사용되므로 Linux 커널과 정적으로 링크된 모든 코드는 GPL을 준수해야 합니다. 로드 가능한 커널 모듈을 동적으로 링크하면 이 요구 사항을 우회할 수 있습니다. 이를 통해 기업은 바이너리 드라이버를 배포할 수 있지만 특정 버전의 Linux 커널에서만 작동한다는 단점이 있습니다. -이 복잡성 때문에, 오늘날 리눅스 및 그와 연관된 소프트웨어에서는 GPL의 법적 효력이 무시되고 있습니다. 이에 대한 장기적인 결과는 불분명합니다. +부분적으로는 그 복잡성으로 인해 오늘날 전 세계 많은 지역에서 리눅스 및 관련 소프트웨어와 관련된 GPL 적법성이 무시되고 있습니다. 이로 인한 장기적인 파급 효과는 불분명합니다. [[origins-lgpl]] == 리눅스와 LGPL의 기원 -상용 유닉스 전쟁이 벌어지는 동안, 리눅스 커널은 PC 유닉스의 클론으로 개발되었습니다. Linus Torvalds는 리눅스의 탄생에 대한 공로를 GNU C 컴파일러 및 그에 연관된 GNU 도구들에 돌리고 있습니다. 그는 리눅스 커널을 GPL로 만들었습니다. +상업용 유닉스 전쟁이 치열하게 벌어지는 동안 리눅스 커널은 PC 유닉스 클론으로 개발되었습니다. 리누스 토발즈(Linus Torvalds)는 리눅스가 존재할 수 있었던 이유로 GNU C 컴파일러와 관련 GNU 도구의 존재를 꼽습니다. 그는 리눅스 커널을 GPL로 배포했습니다. -GPL은 GPL 코드에 정적으로 링크된 모든 코드 역시 GPL을 따르도록 요구하고 있다는 사실을 기억해 주십시오. 즉 해당 프로그램의 소스 코드가 사용자에게 제공되어야 합니다. 그러나 동적 링크는 GPL 위반으로 간주되지 않습니다. 리눅스에서 상용 프로그램을 사용하는 경우가 점점 더 많아졌습니다. 이러한 프로그램들은 대체로 시스템 라이브러리와 링크되어야 합니다. 이 결과로 http://www.opensource.org/licenses/lgpl-license.php[LGPL] ("Library", 나중에 "Lesser"로 다시 명명된, GPL)라고 하는 GPL의 수정판이 나타났습니다. LGPL은 상용 코드를 GNU C 라이브러리인 glibc와 링크하는 것을 허용합니다. 여러분은 LGPL 라이브러리와 동적으로 링크된 코드를 공개해야 할 의무는 없습니다. +GPL은 GPL에 따라, 어떤 코드에 정적으로 링크하는 모든 것도 GPL에 따를 것을 요구한다는 사실을 기억하세요. 따라서 이 코드의 소스는 프로그램 사용자가 사용할 수 있도록 제공되어야 합니다. 그러나 동적 링크는 GPL 위반으로 간주되지 않습니다. 독점 애플리케이션을 Linux에 설치하라는 압력이 압도적으로 커졌습니다. 이러한 애플리케이션은 종종 시스템 라이브러리와 링크해야 합니다. 그 결과 http://www.opensource.org/licenses/lgpl-license.php[LGPL](“라이브러리”, 이후 “Lesser”, GPL로 이름이 변경됨)라는 수정된 버전의 GPL이 탄생했습니다. LGPL은 독점 코드를 GNU C 라이브러리인 glibc에 링크할 수 있도록 허용합니다. LGPL이 적용된 라이브러리에 동적으로 링크된 소스 코드를 공개할 필요는 없습니다. -만약 여러분이 임베디드 시스템에서 흔히 요구되는 것처럼 프로그램과 glibc를 정적으로 링크하고자 한다면, 해당 프로그램을 사유 재산으로 유지할 수는 없습니다. 즉, 소스 코드는 반드시 공개되어야 합니다. GPL과 LGPL 모두 해당 코드를 직접 수정한 것은 공개하도록 요구하고 있습니다. +임베디드 시스템에서 자주 요구되는 것처럼 애플리케이션을 glibc와 정적으로 링크하는 경우 애플리케이션을 독점적으로 유지할 수 없으므로 소스를 공개해야 합니다. GPL과 LGPL 모두, 라이선스의 관리를 받는 코드를 수정할 경우 이를 공개하도록 요구합니다. [[orphaning]] == 오픈 소스 라이선스와 방치 문제 -사유 소프트웨어와 연관된 중요한 문제들 중 하나는 "방치"(orphaning)이라고 알려져 있습니다. 이는 하나의 이는 하나의 사업 실패나 제품 전략 변경이 피라미드 형태로 이에 종속된 많은 시스템과 회사들을 그들이 대처할 수 있는 범위 너머의 이유로 망하게 할 때 일어납니다. 수십 년에 걸친 경험은 잠깐 성공한 소프트웨어 공급자가 그 소프트웨어를 언제까지나 사용 가능하게 해 주지는 않을 것이라는 사실을 보여 주었습니다. 이는 현재의 시장 조건과 전략이 빠르게 변화할 수 있기 때문입니다. +독점 소프트웨어와 관련된 심각한 문제 중 하나는 ‘방치(Orphaning)’로 알려져 있습니다. 이는 어떤 사업의 실패 또는 제품 전략의 변경이 그에 의존하는 시스템의 거대한 피라미드에 영향을 미치는 것을 말하며, 이로인해 기업이 완전히 통제력을 상실하여 발생할 수도 있습니다. 수십 년간의 경험에 따르면 현재의 시장 상황과 전략은 언제든 급변할 수 있기 때문에 소프트웨어 공급업체의 일시적인 규모나 성공이 해당 소프트웨어의 지속적인 사용을 보장하지 않습니다. -GPL은 사유 지적 재산과의 링크를 막음으로써 방치 현상을 방지하고자 하고 있습니다. +GPL은 독점 지적 재산권과의 연결 고리를 끊어 방치화를 방지하고자 합니다. -BSD 라이선스는 중소기업에게 아무런 법적 의무 또는 비용 없이 소프트웨어를 맡겨 놓는 것과 같은 기능을 합니다. 만약 BSD 라이선스 프로그램의 개발이 중단되면, 회사는 그에 종속적인 프로그램을 단순히 사유 재산을 넘겨받듯 계속 사용할 수 있습니다. 보다 나은 상황은 BSD 라이선스의 코드가 비공식 협회에 의해 유지되는 것입니다. 이러면 개발 과정이 하나의 회사 또는 제품 라인의 생존에 종속적이지 않게 됩니다. 개발 팀이 지속적으로 이어지는 것은 단순히 소스 코드를 얻을 수 있는가의 여부보다 훨씬 더 중요합니다. +BSD 라이선스는 소규모 회사에게 법적 복잡성이나 비용 없이 상용기업에 의해 성능을 보장받는 소프트웨어와 동등한 효과를 제공합니다. 만약 BSD 라이선스를 받은 프로그램이 방치 된다면, 다른 회사가 그 프로그램에 의존하고 있는 프로그램을 독점적인 방식으로 인수할 수 있습니다. 개발 프로세스가 단일 회사나 제품 라인의 생존에 의존하지 않기 때문에, 소규모 비공식 컨소시엄에 의해 BSD 코드베이스가 유지되는 경우 더 나은 상황이 발생합니다. 소스 코드의 단순한 물리적 가용성보다 개발 팀이 정신적으로 그 영역에 있을 때의 생존 가능성이 훨씬 더 중요합니다. [[license-cannot]] -== 라이선스가 할 수 없는 일 +== 라이선스로 할 수 없는 일 -어떠한 라이선스도 미래의 소프트웨어 사용 가능성을 보장해 주지는 않습니다. 저작권자가 언제든지 저작권의 내용을 바꿀 수 있지만, BSD 커뮤니티에서 그러한 시도가 있다면 단순히 소스 코드를 fork하게 됩니다. +어떤 라이선스도 미래의 소프트웨어 가용성을 보장할 수는 없습니다. 저작권자는 전통적으로 언제든지 저작권 조건을 변경할 수 있지만, BSD 커뮤니티에서는 그러한 시도가 단순히 소스를 포크하게 만든다고 가정하고 있습니다. -GPL은 라이선스를 무효로 하는 것을 명시적으로 금지하고 있습니다. 그런데 그것이 실제로 일어났습니다. 회사(Mattel)가 GPL 저작권을 인수(cphack)하고, 저작권 전체를 무효화시킨 뒤, 법정에 가서, 승소한 경우[2]입니다. 즉, 그들은 합법적으로 해당 배포본 전체와 모든 파생물에 대한 저작권을 무효화시켰습니다. 더 크고 널리 퍼져 있는 배포폰에 대해서도 이런 일이 일어날 수 있는지는 알 수 없습니다; 뿐만 아니라 특정 소프트웨어가 진짜 GPL인지에 대한 혼란이 있기도 합니다. +GPL은 라이선스 취소를 명시적으로 허용하지 않습니다. 그러나 한 회사(Mattel)가 GPL 저작권(cphack)을 구입한 후 저작권 전체를 취소하고 법정 소송을 제기하여 승소한 사례가 있습니다<>. 즉, 해당 저작권에 기반한 배포판과 2차 저작물 전체를 합법적으로 취소한 것입니다. 더 크고 분산된 배포판에서도 이런 일이 일어날 수 있을지는 아직 미지수이며, 해당 소프트웨어가 실제로 GPL에 따라 배포되었는지에 대해서도 약간의 혼란이 있습니다. -다른 예시로는, Red Hat이 FSF 컴파일러 또구들의 개발을 인수한 기술 회사인 Cygnus를 인수한 경우가 있습니다. Cygnus는 그들이 GNU 소프트웨어에 대한 지원을 판매하는 사업 모델을 개발했기 때문에 이렇게 할 수 있었습니다. 이는 그들로 하여금 50여 명의 엔지니어들을 고용하고 많은 수정을 할 수 있는 우세함을 통해 프로그램의 개발 방향을 원하는 대로 할 수 있게 하였습니다. Donald Rosenberg가 언급하기를 "GPL과 같은 라이선스를 사용하는 프로젝트들은 누군가 더 나은 코드를 만들어 원 소유자에 비해 빠르게 일을 해나가는 방법을 프로젝트를 손에 넣을지도 모른다는 지속적인 위협 속에서 살아간다." [3] +또 다른 예로, 레드햇(Red Hat)은 FSF 컴파일러 도구 개발을 맡았던 엔지니어링 회사인 시그너스(Cygnus)를 인수했습니다. 시그너스를 인수할 수 있었던 이유는 이 회사가 GNU 소프트웨어에 대한 지원을 상품으로 판매하는 비즈니스 모델을 개발했기 때문입니다. 이를 통해 약 50명의 엔지니어를 고용할 수 있었고, 수정 사항을 주도적으로 제안하여 프로그램의 방향을 변경할 수 있었습니다. 도널드 로젠버그(Donald Rosenberg)는 “GPL과 같은 라이선스를 사용하는 프로젝트는… 누군가 더 나은 버전의 코드를 만들어서 기존 소유자보다 더 빨리 프로젝트를 장악할 수 있다는 끊임없는 위협에 시달리고 있다”고 말합니다. <> [[gpl-advantages]] -== GPL의 장단점 +== GPL의 장점과 단점 -GPL을 사용하는 흔한 이유 중 하나는 gcc 컴파일러를 수정하거나 확장할 때입니다. 이것은 모든 소프트웨어의 비용이 비싼 데 비해 결과로 만들어진 컴파일러를 다른 사람이 사용할 가능성이 거의 없는 CPU를 개발할 때 특히 적합합니다. +GPL을 사용하는 일반적인 경우는 gcc 컴파일러를 수정하거나 확장할 때입니다. 이는 특히 모든 소프트웨어 비용이 오버헤드로 간주될 가능성이 높은 환경에서, 일회성으로 특수한 CPU로 작업할 때와 같이 아주 적은 수의 사람만이 변경된 컴파일러를 사용하는 상황에 적합합니다. -GPL은 CD를 판매하는 작은 회사들에게도 매력적일 수 있습니다. 이윤을 충분히 남기면서도 사용자에게 비싸지 않은 제품을 제공할 수 있습니다. GPL은 또한 GPL 지적 재산에 대한 문서 등의 다양한 기술 지원을 제공하는 회사들에게도 매력적입니다. +GPL은 최종 사용자에게 매우 저렴한 제품을 제공하는 “박리다매” 환경에서 CD를 판매하는 소규모 회사와 같은 곳에 매력적입니다. 또한 GPL이 적용된 지적 재산권 세계에서 문서를 포함한 다양한 형태의 기술 지원을 제공함으로써 생존을 기대하는 기업에게도 매력적입니다. -GPL의 잘 알려지지 않고 의도적이지도 않은 사용은 대기업들이 소프트웨어 회사들의 가치를 싸게 평가하는 데 좋다는 것입니다. 다시 말해, GPL은 잠재적으로 전체의 경제적 이익을 저해하고 독과점에 기여하는 마케팅 무기에 적합합니다. +GPL을 따라 충분히 공개하지 않거나 의도치 않게 GPL을 사용하는 것은 소프트웨어 회사를 약화시키려는 대기업에 매우 유리합니다. 즉, GPL은 마케팅 무기로 사용하기에 적합하여 전반적인 경제적 이익을 감소시키고 독과점 행위에 기여할 수 있습니다. -GPL은 소프트웨어를 상업화하고 이윤을 창출하고자 하는 사람들에게는 현실적인 문제가 될 수 있습니다. 예를 들어, GPL은 대학원생이 자신의 연구 결과를 상업화하기 위해 회사를 차리는 것을 어렵게 하거나, 해당 학생이 연구 결과를 상업화해줄 것으로 기대하는 회사에 입사하는 것을 어렵게 합니다. +GPL은 소프트웨어를 상업화하여 수익을 창출하고자 하는 사람들에게 실질적인 문제를 야기할 수 있습니다. 예를 들어, 대학원생이 자신의 연구 결과를 상용화하기 위해 직접 회사를 설립하거나, 유망한 연구 프로젝트의 상용화를 전제로 회사에 입사하는 데 GPL은 어려움을 가중시킬 수 있습니다. -여러 소프트웨어 표준들의 정적 링크 구현을 사용해야 하는 사람들에게 GPL은 좋지 못한 라이선스인데, 이는 상용으로 구현된 표준의 사용을 막기 때문입니다. 그래서 GPL은 GPL 표준을 사용해야 빌드할 수 있는 프로그램의 수를 최소화하고 있습니다. GPL은 하나의 상용 제품이 표준이 되는 방식을 막으려는 의도를 가지고 있습니다. (리눅스 애플리케이션에는 적용되지 않는데, 이는 그것들이 정적 링크 대신 trap-based API를 사용하기 때문입니다.) +여러 소프트웨어 표준의 정적연결로 구현되는 작업을 하는 사람들에게 GPL은 표준의 독점적 구현을 사용할 수 없기 때문에 좋지 않은 라이선스인 경우가 많습니다. 따라서 GPL은 GPL 표준을 사용하여 만들 수 있는 프로그램의 수를 줄이는 결과를 낳았습니다. GPL은 독점적 제품을 개발하는 표준 메커니즘을 제공하지 않기 때문입니다. (Linux 애플리케이션은 정적으로 링크하지 않고 트랩 기반 API를 사용하기 때문에 적용되지 않습니다.) -GPL은 프로그래머들이 프로그램의 발전에 기여하고, 이들의 배포와 지원으로 경쟁하도록 하는 것을 시도하고 있습니다. 이 상황은 필요한 많은 코어 시스템 표준에는 현실적이지 않은데, 이는 이러한 시스템이 기존의 비 GPL 라이선스 표준으로 상용화되거나 그러한 표준과 결합되는 환경에 적용될 수 있기 때문입니다. 실시간 시스템들은 대개 정적으로 링크되기 때문에, 많은 임베디드 시스템 회사들에게 GPL과 LGPL은 단연코 잠재적 문제점으로 여겨집니다. +GPL은 프로그래머들이 진화하는 프로그램 모음에 기여한 후, 이 모음 배포 및 지원에 경쟁하도록 만듭니다. 이러한 상황은 상업적 커스터마이징이나 기존(non-GPL) 라이선스에 따른 레거시 표준과의 통합이 필요한 매우 다양한 환경에 적용될 수 있는, 많은 필수 핵심 시스템 표준에 대해서는 비현실적입니다. 실시간 시스템은 정적으로 연결되는 경우가 많기 때문에 많은 임베디드 시스템 회사에서는 GPL과 LGPL을 잠재적인 문제로 간주하고 있습니다. -GPL은 연구 및 개발 단계에서, 수요에 관계없이, 노력을 유지시키기 위한 시도입니다. 이는 더 널리 배포하는 데 알 수 없는 비용이 드는 연구자 및 개발자들에게 최대한의 혜택을 제공합니다. +GPL은 수요에 관계없이 연구 및 개발 단계 노력의 가치를 유지하려고 합니다. 이를 통해 연구자와 개발자에게는 혜택을 극대화하고, 더 많은 배포를 통해 혜택을 받을 수 있는 사람들에게는 알 수 없는 비용을 요구합니다. -GPL은 연구 결과가 상용 제품으로 변모하는 것을 막기 위해 고안되었습니다. 이는 고전적인 기술이 마침내 다다르게 되는 종착역과 같으며 이렇게 상용화되는 것을 막는 것은 일반적으로 어렵습니다; GPL은 그러한 과정을 봉쇄하도록 만들어졌습니다. +GPL은 연구 결과가 독점적인 제품으로 전환되는 것을 막기 위해 고안되었습니다. 하지만 이 단계는 전통적인 기술 이전 파이프라인의 마지막 단계로 간주되는 경우가 많으며 이런 과정은 일반적으로 최상의 상황에서도 충분히 어려운 일인데, GPL은 이를 아예 불가능하게 만들었다고 받아들여지고 있습니다. [[bsd-advantages]] == BSD의 장점 -BSD 형식의 라이선스는 장기간의 연구 또는 다음과 같은 개발 환경이 필요한 프로젝트에 이상적입니다: +BSD 스타일 라이선스는 장기간의 연구 또는 개발 환경이 필요한 기타 프로젝트에 적합한 선택입니다: -* 거의 비용이 들지 않는 경우 -* 오랜 기간 동안 발전할 경우 -* 누구나 법적 제약 없이 최종 결과물을 상용화하는 것을 허용하고자 할 경우 +* 거의 비용이 없습니다 +* 오랜 기간에 걸쳐 계속 개선될 수 있습니다 +* 누구나 법적 문제를 최소화하면서 최종 결과물을 상용화할 수 있습니다. -마지막 조건은 가장 지배적인 조항인데, 이는 Apache 프로젝트가 그들의 라이선스에 중점을 둔 사항이기도 합니다: +아파치 프로젝트가 라이선스를 결정할 때와 마찬가지로 이 최종 고려사항이 가장 중요한 부분이 될 수 있습니다: -"This type of license is ideal for promoting the use of a reference body of code that implements a protocol for common service. This is another reason why we choose it for the Apache group - many of us wanted to see HTTP survive and become a true multiparty standard, and would not have minded in the slightest if Microsoft or Netscape choose to incorporate our HTTP engine or any other component of our code into their products, if it helped further the goal of keeping HTTP common... All this means that, strategically speaking, the project needs to maintain sufficient momentum, and that participants realize greater value by contributing their code to the project, even code that would have had value if kept proprietary." +“이러한 유형의 라이선스는 공통 서비스를 위한 프로토콜을 구현하는 참조 코드의 사용을 촉진하는 데 이상적입니다. 우리 중 다수는 HTTP가 살아남아 진정한 멀티파티 표준이 되기를 원하며, HTTP의 공용화라는 목표를 달성하는 데 도움이 된다면 Microsoft나 Netscape가 HTTP 엔진이나 우리 코드의 다른 구성 요소를 자사 제품에 통합하는 데 조금도 신경 쓰지 않을 것입니다. 이 모든 것은 전략적으로 볼 때 프로젝트가 계속 충분한 추진력을 유지해야 하며, 참여자들이 자신의 코드를 프로젝트에 기여함으로써 더 큰 가치를 실현할 수 있으며, 심지어 독점적으로 유지되었다면 가치가 있었을 코드도 마찬가지라는 것을 의미합니다.” -개발자들은 BSD 라이선스를 선호하는 경향이 있는데, 이는 그들이 코드를 다룸에 있어 법적 분쟁으로부터 벗어나 그들이 하고 싶은 대로 하도록 허락하기 때문입니다. 반면, 시스템을 개발하기보다 주로 사용할 것으로 예상되는 사람들, 혹은 다른 사람들이 코드를 개선해 주기를 기대하는 사람들, 혹은 (국가 공무원과 같이) 시스템 작업으로 생계를 유지하지는 않는 사람들의 경우 GPL을 선호하는데, 이는 다른 사람이 개발한 코드를 자신이 사용할 수 있고 그들의 상관이 저작권을 가지고 있는 일을 막을 수도 있으며 결과적으로 잠재적으로 소프트웨어를 "무용지물"로 만들거나 방치하지 않도록 할 수 있기 때문입니다. 만약 여러분이 경쟁자로 하여금 여러분을 돕도록 강제하고 싶다면, GPL은 매력적인 선택지가 될 것입니다. +개발자들은 법적인 문제를 피할 수 있고 코드에 대해 원하는 모든 것을 할 수 있다는 점에서 BSD 라이선스가 매력적이라고 생각하는 경향이 있습니다. 반면, 시스템을 프로그래밍하기보다는 주로 시스템을 사용하거나 다른 사람이 코드를 발전시키기를 기대하거나 시스템과 관련된 업무로 생계를 유지하지 않는 사람들(예: 공무원)은 다른 사람이 개발한 코드를 강제로 공개하고 고용주가 저작권을 보유하지 못하게 하여 소프트웨어를 “묻어버리거나” 방치되게 할 수 있는 GPL이 매력적이라고 생각합니다. 경쟁업체의 도움을 받고 싶다면 GPL이 매력적입니다. -BSD 라이선스는 단순한 선물인 것은 아닙니다. "왜 우리는 우리의 경쟁자를 돕거나 그들이 우리가 만든 결과물을 훔쳐 가도록 내버려 두어야 하나요?"라는 질문은 BSD 라이선스에 관련된 질문에서 자주 볼 수 있습니다. BSD 라이선스 하에서, 만약 어떤 회사가 제품 시장을 독점하고 다른 이들이 이를 전략적이었다고 여길 경우, 다른 회사들은 최소한의 노력만으로 시장 경쟁과 공정성을 증대시킬 경쟁 BSD 파생본에 기여하는 작은 협회를 만들 수 있습니다. 이는 각 회사들로 하여금 이것이 제공하는 이점으로부터 이윤을 창출할 수 있을 것이라는 믿음을 주고, 경제적 유연성과 효율성에도 기여할 수 있습니다. 회원들이 더 빠르고 쉽게 이에 협력할수록, 더욱 성공적일 것입니다. BSD 라이선스는 그러한 행동을 가능하게 해 주면서도 가장 덜 복잡한 라이선 스입니다. +BSD 라이선스는 단순한 선물이 아닙니다. “왜 우리가 경쟁사를 도와주거나 경쟁사가 우리의 작업을 훔치도록 내버려둬야 하는가?”라는 질문은 BSD 라이선스와 관련하여 자주 제기됩니다. BSD 라이선스 하에서, 한 회사가 다른 회사가 전략적으로 간주하는 제품의 틈새 시장을 장악하게 되면, 다른 회사들은 최소한의 노력으로 시장 경쟁과 공정성을 높이는 경쟁적 BSD 프로젝트에 기여함으로써 동등성을 회복하는 것을 목표로 하는 미니 컨소시엄을 구성할 수 있습니다. 이를 통해 각 회사는 경제적 유연성과 효율성에 기여하면서 자신이 제공할 수 있는 이점을 통해 이익을 얻을 수 있다고 믿습니다. 협력하는 구성원들이 이를 더 빠르고 쉽게 수행할 수 있을수록 더 큰 성공을 거둘 수 있습니다. BSD 라이선스는 본질적으로 이러한 행동을 가능하게 하는 최소한도의 복잡성을 가진 라이선스입니다. -완전하고 경쟁력 있는 오픈 소스 시스템을 단지 저장 매체의 가격만으로 널리 쓸 수 있게 한다는 GPL의 핵심적인 효과는 합리적인 목표입니다. BSD 형식의 라이선스는, 협회 창설을 통한 개인의 연합을 통해, 기술 개발 과정에 대한 경제적 기대를 저버리지 않고 이 목표를 달성할 수 있습니다. +완전하고 경쟁력 있는 오픈 소스 시스템을 미디어 비용(배포 비용)으로 널리 사용할 수 있도록 하는 것은 GPL의 핵심 효과이며, 이는 합리적인 목표입니다. BSD 스타일의 라이선스는 개인들로 구성된 임시 컨소시엄과 함께 기술 이전 파이프라인의 배포-종료 단계에 구축된 경제적 예상을 파괴하지 않으면서도 이러한 목표를 달성할 수 있습니다. [[recommendations]] -== BSD 라이선스를 사용하면 좋은 경우 +== BSD 라이선스 사용에 대한 구체적 권장사항 -* BSD 라이선스는 연구 결과를 널리 배포하고 경제적 이윤을 창출할 수 있도록 하는 데 적합합니다. 그것으로서, NSF, ONR 그리고 DARPA와 같은 연구 개발 기관은 자금을 투자받은 프로젝트의 초기 단계 연구를 위해 소프트웨어, 데이터, 결과, 그리고 오픈 하드웨어에 BSD 형식의 라이선스를 적용할 것을 장려해야 합니다. 그들은 또한 오픈 소스 시스템 구현과 진행중인 오픈 소스 프로젝트를 기반으로 표준을 정할 것을 장려해야 합니다. -* 정부 정책은 비용과 연구 결과를 실무에 적용할 때의 어려움을 최소화해야 합니다. 가능하다면, 연구 결과를 상용화에 친화적인 BSD 형식의 라이선스로 사용 가능하게 할 것을 요구해야 합니다. -* 많은 경우에, 저작권 또는 특허에 의해 상용 대학 라이선스에 종속되는 것보다 BSD 형식 라이선스의 형식을 취하는 것이 장기적으로 보았을 때 대학의 연구 목표에 더 근접합니다. 대학 입장에서는 장기적으로 보았을 때 연구 결과를 공개하고, 경제적으로 성공한 졸업생들에 의해 기부받는 것이 금전적으로 더 이득이 되는 실제적인 사례들이 존재합니다. -* 회사들은 사실상의 표준을 만드는 것이 마케팅 기술의 핵심이 된다는 것을 오랜 경험에 걸쳐 알아왔습니다. 만약 회사가 시스템을 발전시키는 데 독특한 강점이 있다면, BSD 라이선스는 이 역할을 잘 수행합니다. 라이선스는 회사의 전문 기술 덕분에 그들이 통제할 수 있으면서도 많은 사람들에게 법적인 관점에서 매력적입니다. 다른 사람들을 방해하거나 그들의 것을 빼앗고자 할 목적으로 그러한 표준을 만드는 경우 GPL은 적절한 선택이 될 수 있습니다. 그러나 GPL은 상용으로 적용 가능한 표준을 지향하지 않고 방해합니다. 그러한 GPL suite를 사용하는 것은 지속적으로 상용화와 법률 상의 문제를 발생시킵니다. GPL 표준과 그렇지 않은 것을 함께 활용하는 것은 대개 가능하지 않습니다. 진정한 기술 표준은 기술적이지 않은 이유 때문에 다른 표준 배제할 것을 강제해서는 안 됩니다. -* 다른 회사들의 상용 제품의 핵심이 될 수 있는 표준을 개발하고 장려하는 데 관심이 있는 회사는 GPL에 대해 조심해야 합니다. 사용된 라이선스에 관계없이, 결과가 되는 소프트웨어는 기술적인 변화의 대부분과 시스템의 상태를 가장 잘 아는 사람들에게 맡겨질 것입니다. GPL은 단지 결과에 추가적인 법적 제약을 가할 뿐입니다. -* 오픈 소스 코드를 개발하는 큰 회사는 오픈 소스를 옹호하는 프로그래머를 조심해야 하는데, 이는 그들이 다른 곳으로 이직할 경우에도 여전히 그 소프트웨어를 사용할 수 있기 때문입니다. 일부 회사들은, 특히 해당 소프트웨어가 핵심 전략에 직접적으로 연관되어 있지 않을 때, 이러한 행동을 직원들의 특권으로써 장려합니다. 이는 사실 직접적인 비용 손실 없이 잠재적인 기회 비용만을 잃는 퇴직 혜택입니다. 직원을 회사 외부를 위해 일하도록 장려하는 것은 종종 회사가 손해 없이 제공할 수 있는 간단한 혜택이 되기도 합니다. -* 소프트웨어가 방치될 것이 걱정되는 작은 개발 회사는, 가능하다면 BSD 라이선스를 사용하는 것을 고려해볼 필요가 있습니다. 회사들은 그 규모에 관계없이 BSD 형식 오픈 소스 프로젝트를 구성함으로써 법적인, 그리고 구조적인 간접 비용을 최소화하는 상호간의 이익을 도모할 수 있습니다. -* 비영리단체들은 가능하다면 오픈 소스 프로젝트에 참여해야 합니다. 서로 다른 라이선스의 코드를 함께 사용하는 것과 같은 소프트웨어상의 문제를 최소화하기 위해, BSD 형식의 라이선스가 장려되어야 합니다. 소프트웨어 개발과 밀접하게 관련있는 비영리단체는 GPL을 더욱 경계해야 할 것입니다. 법률을 적용하는 일이 많은 비용을 요구하는 일부 지역에서는, GPL에 비해 단순한 BSD 라이선스가 고려해볼 만한 이점이 될 것입니다. +* BSD 라이선스는 연구 결과를 널리 배포하고 경제에 가장 큰 혜택을 줄 수 있는 방식으로 이전하는 데 바람직합니다. 따라서 NSF, ONR, DARPA와 같은 연구자금 지원 기관은 자금 지원 연구 프로젝트의 초기 단계에서 소프트웨어, 데이터, 결과물, 개방형 하드웨어에 BSD 스타일의 라이선스를 채택하도록 장려해야 합니다. 또한 구현된 오픈 소스 시스템과 진행 중인 오픈 소스 프로젝트를 중심으로 표준을 형성하도록 장려해야 합니다. +* 정부 정책은 연구에서 배포로 이동하는 데 드는 비용과 어려움을 최소화해야 합니다. 가능한 경우, 지원금은 상업화 친화적인 BSD 스타일의 라이선스에 따라 결과를 사용할 수 있도록 요구해야 합니다. +* 많은 경우, BSD 스타일 라이선스의 장기적인 결과는 연구 결과가 저작권이나 특허로 보호되고 대학의 독점적인 라이선스를 따를 때보다 대학의 연구 헌장에 명시된 목표를 더 정확하게 반영합니다. 연구 결과를 공개하고 상업적으로 성공한 동문들의 기부에 호소함으로써 대학이 장기적으로 재정적으로 더 나은 보상을 받는다는 일화가 존재합니다. +* 기업들은 사실상의 표준을 만드는 것이 중요한 마케팅 기법이라는 것을 오랫동안 인식해 왔습니다. 기업이 시스템을 발전시키는 데 있어 남들과 차별되는 이점을 가지고 있다면 BSD 라이선스는 이러한 특징에 잘 부합됩니다. 이 라이선스는 법적으로 더 많은 사람들에게 매력적으로 다가갈 수 있으며, 회사가 가진 전문성을 통해 회사의 통제권을 보장할 수 있습니다. 만약 누군가가 기술 표준을 훼손하거나 다른 표준을 채택하려고 할 때, GPL은 그러한 행동에 이용할 수 있는 적합한 수단이 될 수 있습니다. 그러나 GPL은 상업적으로 적용 가능한 표준이 아닌 제품군을 장려하기 때문에 장기적으론 해당 표준의 개선에 불이익을 줍니다. 이러한 제품군을 사용하면 상업화 및 법적 문제가 지속적으로 제기됩니다. 또한 어떤 표준은 GPL을 따르고 어떤 표준 은 그렇지 않은 경우 표준을 혼합하는 것이 불가능할 수도 있습니다. 진정한 기술 표준은 비기술적인 이유로 다른 표준을 배제하도록 요구해서는 안 됩니다. +* 다른 회사의 상용 제품의 핵심이 될 수 있는 진화하는 표준을 홍보하는 데 관심이 있는 기업은 GPL을 주의해야 합니다. 어떤 라이선스를 사용하든, 결과물인 소프트웨어는 일반적으로 엔지니어링 변경의 대부분을 실제로 수행하고 시스템 상태를 가장 잘 이해하는 사람에게 귀속됩니다. GPL은 결과물에 법적 마찰을 더할 뿐입니다. +* 오픈 소스 코드를 개발하는 대기업은 직원이 이직을 하더라도 그 소프트웨어를 계속 사용할 수 있기 때문에 프로그래머들이 오픈 소스를 높이 평가한다는 사실을 인지해야 합니다. 일부 기업에서는 특히 관련된 소프트웨어가 직접적으로 전략적이지 않은 경우 이러한 행동을 고용 특전으로 장려하기도 합니다. 이는 사실상 잠재적인 기회 비용 손실은 있지만 직접적인 비용은 들지 않는 선급 퇴직금과 같습니다. 직원들이 회사 밖에서 동료들의 찬사를 받기 위해 일하도록 장려하는 것은 때때로 회사에게 있어선 거의 단점이 없는 값싼 이동식 혜택을 제공할 수 있습니다(역자 주: 원문에서 “cheap portable benefit”이라고 표현한 것은, 아무래도 회사가 직원을 타 회사에서 데려 왔을때 단순히 그 직원이 개발한 소프트웨어를 마음대로 쓸 수 있다는 뜻 다는, 향후 그 소프트웨어가 업그레이드 될 때의 이득과 직원의 기술력까지 완전히 다 얻을 수 있다는 의미로 쓰인 것 같습니다). +* 방치되기 쉬운 소프트웨어 프로젝트를 가진 소규모 회사는 가능하면 BSD 라이선스를 사용해야 합니다. 회사의 규모가 어떻든 모든 회사는 진정한 BSD 스타일의 오픈 소스 프로젝트 형태의 프로젝트를 통해 최소한의 법적 및 조직 오버헤드를 유지할 수 있어 서로에게 이득이 되므로 이런 방법에 대해 진지한 고려를 해야 합니다. +* 비영리 단체는 가능하면 오픈소스 프로젝트에 참여해야 합니다. 서로 다른 라이선스 하의 코드 혼용과 같은 소프트웨어 엔지니어링 문제를 최소화하려면 BSD 스타일의 라이선스를 권장해야 합니다. 특히 개발도상국과 교류하는 비영리 단체의 경우 GPL을 주의 깊게 살펴야 합니다. 법 적용에 많은 비용이 드는 일부 지역에서는 GPL에 비해 새로운 BSD 라이선스의 단순성이 상당한 이점이 될 수 있습니다. [[conclusion]] -== 맺음말 +== 결론 -오픈 소스 코드의 상용화를 막기 위해 만들어진 GPL과는 달리, BSD 라이선스는 미래의 행동에 최소한의 제약만을 가합니다. 이는 프로젝트나 회사의 필요에 따라 BSD 코드를 오픈 소스로 유지하거나 상용 솔루션에 사용될 수 있도록 허락합니다. 다시 말해서, BSD 라이선스는 개발 과정에서 법적인 시한 폭탄이 되지 않습니다. +오픈 소스 코드의 독점적인 상업화를 방지하기 위해 고안된 GPL과 달리, BSD 라이선스는 향후 행위에 대해 최소한의 제한을 두고 있습니다. 따라서 프로젝트나 회사의 필요에 따라 BSD 코드를 오픈소스로 유지하거나 상용 솔루션에 통합할 수 있습니다. 다시 말해, BSD 라이선스는 개발 과정의 어느 시점에서도 법적 시한폭탄이 되지 않습니다. -더불어 BSD 라이선스는, GPL이나 LGPL 라이선스와는 달리 복잡한 법적 의무가 주어지지 않기 때문에, 개발자와 회사가 라이선스 위반 여부에 대해 걱정하는 대신 좋은 코드를 작성하고 홍보하는 데 집중할 수 있도록 해 줍니다. +또한, BSD 라이선스는 GPL이나 LGPL 라이선스처럼 법적 복잡성을 수반하지 않기 때문에, 개발자와 회사는 라이선스 위반 여부를 걱정할 필요 없이 좋은 코드를 만들고 홍보하는 데 시간을 할애할 수 있습니다. [[addenda]] -== 추가 정보 +[bibliography] +== 참고 문헌 -[.programlisting] -.... +* [[[one,1]]] http://www.gnu.org/licenses/gpl.html -[1] http://www.gnu.org/licenses/gpl.html +* [[[two,2]]] http://archives.cnn.com/2000/TECH/computing/03/28/cyberpatrol.mirrors/ -[2] http://archives.cnn.com/2000/TECH/computing/03/28/cyberpatrol.mirrors/ +* [[[three,3]]] Open Source: the Unauthorized White Papers, Donald K. Rosenberg, IDG Books, 2000. Quotes are from page 114, "Effects of the GNU GPL". -[3] Open Source: the Unauthorized White Papers, Donald K. Rosenberg, IDG Books, - 2000. Quotes are from page 114, ``Effects of the GNU GPL''. +* [[[four,4]]] In the "What License to Use?" section of http://www.oreilly.com/catalog/opensources/book/brian.html -[4] In the "What License to Use?" section of - http://www.oreilly.com/catalog/opensources/book/brian.html - -This whitepaper is a condensation of an original work available at -http://alumni.cse.ucsc.edu/~brucem/open_source_license.htm -.... +이 백서는 http://alumni.cse.ucsc.edu/~brucem/open_source_license.htm에서 제공되는 원본 저작물을 요약한 것입니다 diff --git a/documentation/content/ko/articles/bsdl-gpl/_index.po b/documentation/content/ko/articles/bsdl-gpl/_index.po new file mode 100644 index 0000000000..123995d569 --- /dev/null +++ b/documentation/content/ko/articles/bsdl-gpl/_index.po @@ -0,0 +1,1078 @@ +# SOME DESCRIPTIVE TITLE +# Copyright (C) YEAR The FreeBSD Project +# This file is distributed under the same license as the FreeBSD Documentation package. +# Kyung-tak, Yoo , 2023. +msgid "" +msgstr "" +"Project-Id-Version: FreeBSD Documentation VERSION\n" +"POT-Creation-Date: 2022-02-01 09:21-0300\n" +"PO-Revision-Date: 2023-03-27 11:54+0000\n" +"Last-Translator: Kyung-tak, Yoo \n" +"Language-Team: Korean \n" +"Language: ko\n" +"MIME-Version: 1.0\n" +"Content-Type: text/plain; charset=UTF-8\n" +"Content-Transfer-Encoding: 8bit\n" +"Plural-Forms: nplurals=1; plural=0;\n" +"X-Generator: Weblate 4.15.1\n" + +#. type: Title = +#: documentation/content/en/articles/bsdl-gpl/_index.adoc:1 +#: documentation/content/en/articles/bsdl-gpl/_index.adoc:11 +#, no-wrap +msgid "Why you should use a BSD style license for your Open Source Project" +msgstr "오픈소스 프로젝트에 BSD 스타일 라이선스를 사용해야 하는 이유" + +#. type: Plain text +#: documentation/content/en/articles/bsdl-gpl/_index.adoc:43 +msgid "'''" +msgstr "'''" + +#. type: Title == +#: documentation/content/en/articles/bsdl-gpl/_index.adoc:47 +#, no-wrap +msgid "Introduction" +msgstr "소개" + +#. type: Plain text +#: documentation/content/en/articles/bsdl-gpl/_index.adoc:52 +msgid "" +"This document makes a case for using a BSD style license for software and " +"data; specifically it recommends using a BSD style license in place of the " +"GPL. It can also be read as a BSD versus GPL Open Source License " +"introduction and summary." +msgstr "" +"이 문서는 소프트웨어와 데이터에 BSD 스타일 라이선스를 사용하는 사례를 " +"제시하며, 특히 GPL 대신 BSD 스타일 라이선스를 사용할 것을 권장합니다. 이 " +"문서는 BSD와 GPL 오픈 소스 라이선스 소개 및 요약으로 생각하셔도 됩니다." + +#. type: Title == +#: documentation/content/en/articles/bsdl-gpl/_index.adoc:54 +#, no-wrap +msgid "Very Brief Open Source History" +msgstr "아주 간략한 오픈소스 역사" + +#. type: Plain text +#: documentation/content/en/articles/bsdl-gpl/_index.adoc:60 +msgid "" +"Long before the term \"Open Source\" was used, software was developed by " +"loose associations of programmers and freely exchanged. Starting in the " +"early 1950's, organizations such as http://www.share.org[SHARE] and http://" +"www.decus.org[DECUS] developed much of the software that computer hardware " +"companies bundled with their hardware offerings. At that time computer " +"companies were in the hardware business; anything that reduced software cost " +"and made more programs available made the hardware companies more " +"competitive." +msgstr "" +"“오픈 소스”라는 용어가 사용되기 훨씬 전부터 소프트웨어는 프로그래머들의 " +"느슨한 연합에 의해 개발되고 자유롭게 교환되었습니다. 1950년대 초부터 " +"http://www.share.org[SHARE] 및 http://www.decus.org[DECUS]와 같은 조직이 " +"컴퓨터 하드웨어 회사가 하드웨어 제품에 번들로 제공하는 소프트웨어의 대부분을 " +"개발했습니다. 당시 컴퓨터 회사들은 하드웨어를 주축으로 사업을 하고 있었기 " +"때문에 소프트웨어 비용을 절감하고 더 많은 프로그램을 사용할 수 있게 하면 " +"컴퓨터 회사의 경쟁력이 높아졌습니다." + +#. type: Plain text +#: documentation/content/en/articles/bsdl-gpl/_index.adoc:67 +msgid "" +"This model changed in the 1960's. In 1965 ADR developed the first licensed " +"software product independent of a hardware company. ADR was competing " +"against a free IBM package originally developed by IBM customers. ADR " +"patented their software in 1968. To stop sharing of their program, they " +"provided it under an equipment lease in which payment was spread over the " +"lifetime of the product. ADR thus retained ownership and could control " +"resale and reuse." +msgstr "" +"이 모델은 1960년대에 바뀌었습니다. 1965년 ADR은 하드웨어 회사로부터 " +"독립하여 최초의 라이선스 소프트웨어 제품을 개발했습니다. ADR은 원래 IBM " +"고객이 개발한 무료 IBM 패키지와 경쟁하고 있었습니다. ADR은 1968년 " +"소프트웨어 특허를 획득했습니다. 프로그램의 공유를 막기 위해 제품 수명 기간 " +"동안 요금을 나눠내는 장비 리스 방식으로 제품을 제공했습니다. 따라서 ADR은 " +"소유권을 유지하고 재판매 및 재사용을 통제할 수 있었습니다." + +#. type: Plain text +#: documentation/content/en/articles/bsdl-gpl/_index.adoc:70 +msgid "" +"In 1969 the US Department of Justice charged IBM with destroying businesses " +"by bundling free software with IBM hardware. As a result of this suit, IBM " +"unbundled its software; that is, software became independent products " +"separate from hardware." +msgstr "" +"1969년 미국 법무부는 IBM이 무료 소프트웨어를 IBM 하드웨어에 번들로 " +"제공함으로써 비즈니스를 파괴했다는 혐의로 IBM을 기소했습니다. 이 소송의 " +"결과로 IBM은 소프트웨어를 번들에서 분리하였고, 소프트웨어가 하드웨어와 " +"분리된 독립적인 제품이 되었습니다." + +#. type: Plain text +#: documentation/content/en/articles/bsdl-gpl/_index.adoc:75 +msgid "" +"In 1968 Informatics introduced the first commercial killer-app and rapidly " +"established the concept of the software product, the software company, and " +"very high rates of return. Informatics developed the perpetual license " +"which is now standard throughout the computer industry, wherein ownership is " +"never transferred to the customer." +msgstr "" +"1968년 인포매틱스(Informatics)는 최초의 상용 킬러 앱을 출시하여 소프트웨어 " +"제품, 소프트웨어 회사, 매우 높은 수익률이라는 개념을 빠르게 정립했습니다. " +"인포매틱스는 현재 컴퓨터 업계에서 표준이 된 영구 라이선스를 개발했는데, 이 " +"라이선스는 소유권이 고객에게 이전되지 않습니다." + +#. type: Title == +#: documentation/content/en/articles/bsdl-gpl/_index.adoc:77 +#, no-wrap +msgid "Unix from a BSD Licensing Perspective" +msgstr "BSD 라이선스 관점에서 본 유닉스" + +#. type: Plain text +#: documentation/content/en/articles/bsdl-gpl/_index.adoc:83 +msgid "" +"AT&T, who owned the original Unix implementation, was a publicly regulated " +"monopoly tied up in anti-trust court; it was legally unable to sell a " +"product into the software market. It was, however, able to provide it to " +"academic institutions for the price of media." +msgstr "" +"최초의 유닉스 구현을 소유한 AT&T는 미국의 반독점법에 묶여 공공 규제를 받는 " +"독점기업이었기 때문에 법적으로 소프트웨어 시장에 제품을 판매할 수 " +"없었습니다. 하지만 학술 기관에는 미디어 가격(순수한 패키지 가격)을 받고 " +"제공할 수 있었습니다." + +#. type: Plain text +#: documentation/content/en/articles/bsdl-gpl/_index.adoc:89 +msgid "" +"Universities rapidly adopted Unix after an OS conference publicized its " +"availability. It was extremely helpful that Unix ran on the PDP-11, a very " +"affordable 16-bit computer, and was coded in a high-level language that was " +"demonstrably good for systems programming. The DEC PDP-11 had, in effect, " +"an open hardware interface designed to make it easy for customers to write " +"their own OS, which was common. As DEC founder Ken Olsen famously " +"proclaimed, \"software comes from heaven when you have good hardware\"." +msgstr "" +"한 OS 컨퍼런스에서 유닉스를 공적으로 사용할 수 있다는 사실이 알려지면서 많은 " +"대학들은 빠르게 유닉스를 도입했습니다. 유닉스가 매우 저렴한 16비트 컴퓨터인 " +"PDP-11에서 실행되고 시스템 프로그래밍에 매우 적합한 고급 언어로 코딩되어 " +"있었다는 점이 큰 도움이 되었습니다. DEC PDP-11은 고객이 자체 OS를 쉽게 " +"작성할 수 있도록 설계된 개방형 하드웨어 인터페이스를 갖추고 있었는데, " +"당시에는 이러한 인터페이스가 일반적이었습니다. “좋은 하드웨어가 있으면 " +"소프트웨어는 하늘에서 내려온다”는 DEC 창립자 켄 올슨(Ken Olsen)의 유명한 " +"명언이 있습니다." + +#. type: Plain text +#: documentation/content/en/articles/bsdl-gpl/_index.adoc:95 +msgid "" +"Unix author Ken Thompson returned to his alma mater, University of " +"California Berkeley (UCB), in 1975 and taught the kernel line-by-line. This " +"ultimately resulted in an evolving system known as BSD (Berkeley Standard " +"Distribution). UCB converted Unix to 32-bits, added virtual memory, and " +"implemented the version of the TCP/IP stack upon which the Internet was " +"essentially built. UCB made BSD available for the cost of media, under what " +"became known as \"the BSD license\". A customer purchased Unix from AT&T " +"and then ordered a BSD tape from UCB." +msgstr "" +"유닉스의 창시자 켄 톰슨(Ken Thompson)은 1975년 모교인 캘리포니아 버클리 " +"대학교(UCB)로 돌아와 커널을 한 줄 한 줄 가르쳤습니다. 그 결과 BSD(버클리 " +"표준 배포판)로 알려진 진화하는 시스템이 탄생했습니다. UCB는 유닉스를 " +"32비트로 변환하고, 가상 메모리를 추가하고, 인터넷의 기본이 되는 TCP/IP 스택 " +"버전을 구현했습니다. UCB는 “BSD 라이선스”라는 이름으로 미디어 비용으로 " +"BSD를 사용할 수 있게 했습니다. 과거에 AT&T에서 유닉스를 구입한 고객들은 " +"이제 UCB에서 BSD 테이프를 주문하게 되었습니다." + +#. type: Plain text +#: documentation/content/en/articles/bsdl-gpl/_index.adoc:99 +msgid "" +"In the mid-1980s a government anti-trust case against AT&T ended with the " +"break-up of AT&T. AT&T still owned Unix and was now able to sell it. AT&T " +"embarked on an aggressive licensing effort and most commercial Unixes of the " +"day became AT&T-derived." +msgstr "" +"1980년대 중반, AT&T에 대한 정부의 반독점 소송으로 인해 AT&T가 " +"해체되었습니다. AT&T는 여전히 유닉스를 소유하고 있었으며 이제 이를 판매할 " +"수 있게 되었습니다. AT&T는 공격적인 라이선스 확보에 나섰고, 당시 대부분의 " +"상용 유닉스는 AT&T에서 파생된 제품이 되었습니다." + +#. type: Plain text +#: documentation/content/en/articles/bsdl-gpl/_index.adoc:105 +msgid "" +"In the early 1990's AT&T sued UCB over license violations related to BSD. " +"UCB discovered that AT&T had incorporated, without acknowledgment or " +"payment, many improvements due to BSD into AT&T's products, and a lengthy " +"court case, primarily between AT&T and UCB, ensued. During this period some " +"UCB programmers embarked on a project to rewrite any AT&T code associated " +"with BSD. This project resulted in a system called BSD 4.4-lite (lite " +"because it was not a complete system; it lacked 6 key AT&T files)." +msgstr "" +"1990년대 초, AT&T는 BSD와 관련된 라이선스 위반으로 UCB를 고소했습니다. 이 " +"과정에서 UCB는 AT&T가 BSD로 인한 많은 개선 사항을 승인이나 대가 없이 AT&T의 " +"제품에 통합했다는 사실을 발견했고, AT&T와 UCB 간의 오랜 법정 소송이 " +"이어졌습니다. 이 기간 동안 일부 UCB 프로그래머들은 BSD와 관련된 모든 AT&T " +"코드를 다시 작성하는 프로젝트에 착수했습니다. 이 프로젝트는 BSD 4.4-" +"lite라는 시스템을 탄생시켰습니다(라이트라고 명명한 것은 6개의 주요 AT&T " +"파일이 부족해 완전한 시스템이 아니었기 때문입니다)." + +#. type: Plain text +#: documentation/content/en/articles/bsdl-gpl/_index.adoc:109 +msgid "" +"A lengthy series of articles published slightly later in Dr. Dobbs magazine " +"described a BSD-derived 386 PC version of Unix, with BSD-licensed " +"replacement files for the 6 missing 4.4 lite files. This system, named " +"386BSD, was due to ex-UCB programmer William Jolitz. It became the original " +"basis of all the PC BSDs in use today." +msgstr "" +"조금 후에 닥터 돕스(Dr. Dobbs) 잡지에 실린 긴 기사 시리즈에서는 누락된 6개의 " +"4.4 라이트 파일에 대한 BSD 라이선스 대체 파일과 함께 BSD 파생 386 PC 버전의 " +"유닉스에 대해 설명했습니다. 386BSD로 명명된 이 시스템은 전직 UCB 프로그래머 " +"윌리엄 졸리츠(William Jolitz)가 만든 것입니다. 이 시스템은 현재 사용 중인 " +"모든 PC BSD의 기반이 되었습니다." + +#. type: Plain text +#: documentation/content/en/articles/bsdl-gpl/_index.adoc:112 +msgid "" +"In the mid 1990s, Novell purchased AT&T's Unix rights and a (then secret) " +"agreement was reached to terminate the lawsuit. UCB soon terminated its " +"support for BSD." +msgstr "" +"1990년대 중반, 노벨(Novell)은 AT&T의 유닉스 권리를 인수했고, 소송을 " +"종료하기로 (당시엔 비밀리에) 합의가 이루어졌습니다. UCB는 곧 BSD에 대한 " +"지원을 종료했습니다." + +#. type: Title == +#: documentation/content/en/articles/bsdl-gpl/_index.adoc:114 +#, no-wrap +msgid "The Current State of FreeBSD and BSD Licenses" +msgstr "FreeBSD의 현황과 BSD 라이선스" + +#. type: Plain text +#: documentation/content/en/articles/bsdl-gpl/_index.adoc:120 +msgid "" +"The so-called http://www.opensource.org/licenses/bsd-license.php[new BSD " +"license] applied to FreeBSD within the last few years is effectively a " +"statement that you can do anything with the program or its source, but you " +"do not have any warranty and none of the authors has any liability " +"(basically, you cannot sue anybody). This new BSD license is intended to " +"encourage product commercialization. Any BSD code can be sold or included " +"in proprietary products without any restrictions on the availability of your " +"code or your future behavior." +msgstr "" +"지난 몇 년 동안 FreeBSD에 적용된 소위 http://www.opensource.org/licenses/bsd-" +"license.php[new BSD license]는 사실상 프로그램이나 그 소스로 무엇이든 할 수 " +"있지만, 그 어떤 보증도 없고, 어떤 저작자도 책임을 지지 않는다는 선언입니다(" +"기본적으로 누구에게도 소송을 제기할 수 없습니다). 이 새로운 BSD 라이선스는 " +"제품 상용화를 장려하기 위한 것입니다. 모든 BSD 코드는 코드의 가용성이나 " +"향후 행위에 대한 제한 없이 판매되거나 독점 제품에 포함될 수 있습니다." + +#. type: Plain text +#: documentation/content/en/articles/bsdl-gpl/_index.adoc:123 +msgid "" +"Do not confuse the new BSD license with \"public domain\". While an item in " +"the public domain is also free for all to use, it has no owner." +msgstr "" +"새로운 BSD 라이선스를 “퍼블릭 도메인”과 혼동하지 마세요. 퍼블릭 도메인의 " +"항목도 누구나 무료로 사용할 수 있지만 소유자가 없습니다." + +#. type: Title == +#: documentation/content/en/articles/bsdl-gpl/_index.adoc:125 +#, no-wrap +msgid "The origins of the GPL" +msgstr "GPL의 유래" + +#. type: Plain text +#: documentation/content/en/articles/bsdl-gpl/_index.adoc:129 +msgid "" +"While the future of Unix had been so muddled in the late 1980s and early " +"1990s, the GPL, another development with important licensing considerations, " +"reached fruition." +msgstr "1980년대 말과 1990년대 초, 유닉스의 미래가 매우 혼란스러웠을 때 라이선스를 " +"중요하게 고려한 GPL이 나타났습니다." + +#. type: Plain text +#: documentation/content/en/articles/bsdl-gpl/_index.adoc:138 +msgid "" +"Richard Stallman, the developer of Emacs, was a member of the staff at MIT " +"when his lab switched from home-grown to proprietary systems. Stallman " +"became upset when he found that he could not legally add minor improvements " +"to the system. (Many of Stallman's co-workers had left to form two " +"companies based on software developed at MIT and licensed by MIT; there " +"appears to have been disagreement over access to the source code for this " +"software). Stallman devised an alternative to the commercial software " +"license and called it the GPL, or \"GNU Public License\". He also started a " +"non-profit foundation, the http://www.fsf.org[Free Software Foundation] " +"(FSF), which intended to develop an entire operating system, including all " +"associated software, that would not be subject to proprietary licensing. " +"This system was called GNU, for \"GNU is Not Unix\"." +msgstr "" +"Emacs의 개발자인 리처드 스톨먼(Richard Stallman)은 MIT에서 연구실을 자체 " +"개발 시스템에서 독점 시스템으로 전환할 당시 직원으로 근무하고 있었습니다. " +"스톨만은 시스템에 사소한 개선 사항을 법적으로 추가할 수 없다는 사실을 알게 " +"되자 화가 났습니다. (스톨만의 동료들 중 다수는 MIT에서 개발하고 MIT가 " +"라이선스를 부여한 소프트웨어를 기반으로 한 두 개의 회사를 설립하기 위해 " +"회사를 떠났는데, 이 소프트웨어의 소스 코드에 대한 접근 권한에 대해 이견이 " +"있었던 것으로 보입니다). 스톨만은 상용 소프트웨어 라이선스에 대한 대안을 " +"고안해냈고 이를 GPL, 즉 “GNU 공중 라이선스”라고 불렀습니다. 또한 그는 " +"비영리 재단인 http://www.fsf.org[자유 소프트웨어 재단](FSF)을 설립하여 모든 " +"관련 소프트웨어를 포함한 전체 운영 체제를 독점 라이선스의 적용을 받지 않는 " +"것으로 개발하고자 했습니다. 이 시스템은 “GNU는 유닉스가 아니다”라는 뜻에서 " +"GNU라고 불렀습니다." + +#. type: Plain text +#: documentation/content/en/articles/bsdl-gpl/_index.adoc:143 +msgid "" +"The GPL was designed to be the antithesis of the standard proprietary " +"license. To this end, any modifications that were made to a GPL program " +"were required to be given back to the GPL community (by requiring that the " +"source of the program be available to the user) and any program that used or " +"linked to GPL code was required to be under the GPL. The GPL was intended " +"to keep software from becoming proprietary. As the last paragraph of the " +"GPL states:" +msgstr "" +"GPL은 표준 독점 라이선스와 반대되는 개념으로 설계되었습니다. 이를 위해 GPL " +"프로그램을 수정할 경우 해당 프로그램의 소스를 사용자가 원하면 접근할 수 " +"있도록 GPL 커뮤니티에 환원해야 했고, GPL 코드를 사용하거나 링크하는 모든 " +"프로그램은 GPL에 따라 사용해야 했습니다. GPL은 소프트웨어가 독점적인 " +"소유물이 되는 것을 막기 위한 것입니다. GPL의 마지막 단락에 명시되어 있듯이:" + +#. type: Plain text +#: documentation/content/en/articles/bsdl-gpl/_index.adoc:145 +msgid "" +"\"This General Public License does not permit incorporating your program " +"into proprietary programs.\"<>" +msgstr "“본 일반 공중 사용 허가서는 귀하의 프로그램을 독점 프로그램에 통합하는 것을 " +"허용하지 않습니다.”<>" + +#. type: Plain text +#: documentation/content/en/articles/bsdl-gpl/_index.adoc:147 +msgid "" +"The http://www.opensource.org/licenses/gpl-license.php[GPL] is a complex " +"license so here are some rules of thumb when using the GPL:" +msgstr "" +"http://www.opensource.org/licenses/gpl-license.php[GPL]은 복잡한 " +"라이선스이므로 GPL을 사용할 때 지켜야 할 몇 가지 규칙이 있습니다:" + +#. type: Plain text +#: documentation/content/en/articles/bsdl-gpl/_index.adoc:149 +msgid "" +"you can charge as much as you want for distributing, supporting, or " +"documenting the software, but you cannot sell the software itself." +msgstr "소프트웨어 배포, 지원 또는 문서화 비용은 얼마든지 청구할 수 있지만 " +"소프트웨어 자체는 판매할 수 없습니다." + +#. type: Plain text +#: documentation/content/en/articles/bsdl-gpl/_index.adoc:150 +msgid "" +"the rule-of-thumb states that if GPL source is required for a program to " +"compile, the program must be under the GPL. Linking statically to a GPL " +"library requires a program to be under the GPL." +msgstr "" +"일반적인 원칙상, 프로그램을 컴파일하는 데 GPL 소스가 필요한 경우 해당 " +"프로그램은 반드시 GPL에 따라야 합니다. 또한 GPL 라이브러리에 정적으로 " +"링크하려면 프로그램은 GPL을 따라야 합니다." + +#. type: Plain text +#: documentation/content/en/articles/bsdl-gpl/_index.adoc:151 +msgid "" +"the GPL requires that any patents associated with GPLed software must be " +"licensed for everyone's free use." +msgstr "GPL에 따르면 GPL 소프트웨어와 관련된 모든 특허는 모든 사람이 자유롭게 사용할 " +"수 있도록 라이선스가 부여되어야 합니다." + +#. type: Plain text +#: documentation/content/en/articles/bsdl-gpl/_index.adoc:152 +msgid "" +"simply aggregating software together, as when multiple programs are put on " +"one disk, does not count as including GPLed programs in non-GPLed programs." +msgstr "" +"여러 프로그램을 하나의 디스크에 넣을 때처럼 단순히 소프트웨어를 한데 모으는 " +"것은 GPL이 아닌 프로그램에 GPL이 적용된 프로그램을 포함하는 것으로 간주하지 " +"않습니다." + +#. type: Plain text +#: documentation/content/en/articles/bsdl-gpl/_index.adoc:153 +msgid "" +"output of a program does not count as a derivative work. This enables the " +"gcc compiler to be used in commercial environments without legal problems." +msgstr "" +"프로그램의 결과물은 2차적 저작물로 간주되지 않습니다. 따라서 gcc 컴파일러는 " +"법적 문제 없이 상업적 환경에서 사용할 수 있습니다." + +#. type: Plain text +#: documentation/content/en/articles/bsdl-gpl/_index.adoc:154 +msgid "" +"since the Linux kernel is under the GPL, any code statically linked with the " +"Linux kernel must be GPLed. This requirement can be circumvented by " +"dynamically linking loadable kernel modules. This permits companies to " +"distribute binary drivers, but often has the disadvantage that they will " +"only work for particular versions of the Linux kernel." +msgstr "" +"Linux 커널은 GPL에 따라 사용되므로 Linux 커널과 정적으로 링크된 모든 코드는 " +"GPL을 준수해야 합니다. 로드 가능한 커널 모듈을 동적으로 링크하면 이 요구 " +"사항을 우회할 수 있습니다. 이를 통해 기업은 바이너리 드라이버를 배포할 수 " +"있지만 특정 버전의 Linux 커널에서만 작동한다는 단점이 있습니다." + +#. type: Plain text +#: documentation/content/en/articles/bsdl-gpl/_index.adoc:157 +msgid "" +"Due in part to its complexity, in many parts of the world today the " +"legalities of the GPL are being ignored in regard to Linux and related " +"software. The long-term ramifications of this are unclear." +msgstr "" +"부분적으로는 그 복잡성으로 인해 오늘날 전 세계 많은 지역에서 리눅스 및 관련 " +"소프트웨어와 관련된 GPL 적법성이 무시되고 있습니다. 이로 인한 장기적인 파급 " +"효과는 불분명합니다." + +#. type: Title == +#: documentation/content/en/articles/bsdl-gpl/_index.adoc:159 +#, no-wrap +msgid "The origins of Linux and the LGPL" +msgstr "리눅스와 LGPL의 기원" + +#. type: Plain text +#: documentation/content/en/articles/bsdl-gpl/_index.adoc:164 +msgid "" +"While the commercial Unix wars raged, the Linux kernel was developed as a PC " +"Unix clone. Linus Torvalds credits the existence of the GNU C compiler and " +"the associated GNU tools for the existence of Linux. He put the Linux " +"kernel under the GPL." +msgstr "" +"상업용 유닉스 전쟁이 치열하게 벌어지는 동안 리눅스 커널은 PC 유닉스 클론으로 " +"개발되었습니다. 리누스 토발즈(Linus Torvalds)는 리눅스가 존재할 수 있었던 " +"이유로 GNU C 컴파일러와 관련 GNU 도구의 존재를 꼽습니다. 그는 리눅스 커널을 " +"GPL로 배포했습니다." + +#. type: Plain text +#: documentation/content/en/articles/bsdl-gpl/_index.adoc:173 +msgid "" +"Remember that the GPL requires anything that statically links to any code " +"under the GPL also be placed under the GPL. The source for this code must " +"thus be made available to the user of the program. Dynamic linking, " +"however, is not considered a violation of the GPL. Pressure to put " +"proprietary applications on Linux became overwhelming. Such applications " +"often must link with system libraries. This resulted in a modified version " +"of the GPL called the http://www.opensource.org/licenses/lgpl-license." +"php[LGPL] (\"Library\", since renamed to \"Lesser\", GPL). The LGPL allows " +"proprietary code to be linked to the GNU C library, glibc. You do not have " +"to release the source code which has been dynamically linked to an LGPLed " +"library." +msgstr "" +"GPL은 GPL에 따라, 어떤 코드에 정적으로 링크하는 모든 것도 GPL에 따를 것을 " +"요구한다는 사실을 기억하세요. 따라서 이 코드의 소스는 프로그램 사용자가 " +"사용할 수 있도록 제공되어야 합니다. 그러나 동적 링크는 GPL 위반으로 " +"간주되지 않습니다. 독점 애플리케이션을 Linux에 설치하라는 압력이 압도적으로 " +"커졌습니다. 이러한 애플리케이션은 종종 시스템 라이브러리와 링크해야 " +"합니다. 그 결과 http://www.opensource.org/licenses/lgpl-license." +"php[LGPL](“라이브러리”, 이후 “Lesser”, GPL로 이름이 변경됨)라는 수정된 " +"버전의 GPL이 탄생했습니다. LGPL은 독점 코드를 GNU C 라이브러리인 glibc에 " +"링크할 수 있도록 허용합니다. LGPL이 적용된 라이브러리에 동적으로 링크된 " +"소스 코드를 공개할 필요는 없습니다." + +#. type: Plain text +#: documentation/content/en/articles/bsdl-gpl/_index.adoc:177 +msgid "" +"If you statically link an application with glibc, such as is often required " +"in embedded systems, you cannot keep your application proprietary, that is, " +"the source must be released. Both the GPL and LGPL require any " +"modifications to the code directly under the license to be released." +msgstr "" +"임베디드 시스템에서 자주 요구되는 것처럼 애플리케이션을 glibc와 정적으로 " +"링크하는 경우 애플리케이션을 독점적으로 유지할 수 없으므로 소스를 공개해야 " +"합니다. GPL과 LGPL 모두, 라이선스의 관리를 받는 코드를 수정할 경우 이를 " +"공개하도록 요구합니다." + +#. type: Title == +#: documentation/content/en/articles/bsdl-gpl/_index.adoc:179 +#, no-wrap +msgid "Open Source licenses and the Orphaning Problem" +msgstr "오픈 소스 라이선스와 방치 문제" + +#. type: Plain text +#: documentation/content/en/articles/bsdl-gpl/_index.adoc:184 +msgid "" +"One of the serious problems associated with proprietary software is known as " +"\"orphaning\". This occurs when a single business failure or change in a " +"product strategy causes a huge pyramid of dependent systems and companies to " +"fail for reasons beyond their control. Decades of experience have shown " +"that the momentary size or success of a software supplier is no guarantee " +"that their software will remain available, as current market conditions and " +"strategies can change rapidly." +msgstr "" +"독점 소프트웨어와 관련된 심각한 문제 중 하나는 ‘방치(Orphaning)’로 알려져 " +"있습니다. 이는 어떤 사업의 실패 또는 제품 전략의 변경이 그에 의존하는 " +"시스템의 거대한 피라미드에 영향을 미치는 것을 말하며, 이로인해 기업이 완전히 " +"통제력을 상실하여 발생할 수도 있습니다. 수십 년간의 경험에 따르면 현재의 " +"시장 상황과 전략은 언제든 급변할 수 있기 때문에 소프트웨어 공급업체의 " +"일시적인 규모나 성공이 해당 소프트웨어의 지속적인 사용을 보장하지 않습니다." + +#. type: Plain text +#: documentation/content/en/articles/bsdl-gpl/_index.adoc:186 +msgid "" +"The GPL attempts to prevent orphaning by severing the link to proprietary " +"intellectual property." +msgstr "GPL은 독점 지적 재산권과의 연결 고리를 끊어 방치화를 방지하고자 합니다." + +#. type: Plain text +#: documentation/content/en/articles/bsdl-gpl/_index.adoc:191 +msgid "" +"A BSD license gives a small company the equivalent of software-in-escrow " +"without any legal complications or costs. If a BSD-licensed program becomes " +"orphaned, a company can simply take over, in a proprietary manner, the " +"program on which they are dependent. An even better situation occurs when a " +"BSD code-base is maintained by a small informal consortium, since the " +"development process is not dependent on the survival of a single company or " +"product line. The survivability of the development team when they are " +"mentally in the zone is much more important than simple physical " +"availability of the source code." +msgstr "" +"BSD 라이선스는 소규모 회사에게 법적 복잡성이나 비용 없이 상용기업에 의해 " +"성능을 보장받는 소프트웨어와 동등한 효과를 제공합니다. 만약 BSD 라이선스를 " +"받은 프로그램이 방치 된다면, 다른 회사가 그 프로그램에 의존하고 있는 " +"프로그램을 독점적인 방식으로 인수할 수 있습니다. 개발 프로세스가 단일 " +"회사나 제품 라인의 생존에 의존하지 않기 때문에, 소규모 비공식 컨소시엄에 " +"의해 BSD 코드베이스가 유지되는 경우 더 나은 상황이 발생합니다. 소스 코드의 " +"단순한 물리적 가용성보다 개발 팀이 정신적으로 그 영역에 있을 때의 생존 " +"가능성이 훨씬 더 중요합니다." + +#. type: Title == +#: documentation/content/en/articles/bsdl-gpl/_index.adoc:193 +#, no-wrap +msgid "What a license cannot do" +msgstr "라이선스로 할 수 없는 일" + +#. type: Plain text +#: documentation/content/en/articles/bsdl-gpl/_index.adoc:197 +msgid "" +"No license can guarantee future software availability. Although a copyright " +"holder can traditionally change the terms of a copyright at anytime, the " +"presumption in the BSD community is that such an attempt simply causes the " +"source to fork." +msgstr "" +"어떤 라이선스도 미래의 소프트웨어 가용성을 보장할 수는 없습니다. 저작권자는 " +"전통적으로 언제든지 저작권 조건을 변경할 수 있지만, BSD 커뮤니티에서는 " +"그러한 시도가 단순히 소스를 포크하게 만든다고 가정하고 있습니다." + +#. type: Plain text +#: documentation/content/en/articles/bsdl-gpl/_index.adoc:203 +msgid "" +"The GPL explicitly disallows revoking the license. It has occurred, " +"however, that a company (Mattel) purchased a GPL copyright (cphack), revoked " +"the entire copyright, went to court, and prevailed <>. That is, they " +"legally revoked the entire distribution and all derivative works based on " +"the copyright. Whether this could happen with a larger and more dispersed " +"distribution is an open question; there is also some confusion regarding " +"whether the software was really under the GPL." +msgstr "" +"GPL은 라이선스 취소를 명시적으로 허용하지 않습니다. 그러나 한 회사(Mattel)" +"가 GPL 저작권(cphack)을 구입한 후 저작권 전체를 취소하고 법정 소송을 " +"제기하여 승소한 사례가 있습니다<>. 즉, 해당 저작권에 기반한 배포판과 " +"2차 저작물 전체를 합법적으로 취소한 것입니다. 더 크고 분산된 배포판에서도 " +"이런 일이 일어날 수 있을지는 아직 미지수이며, 해당 소프트웨어가 실제로 GPL에 " +"따라 배포되었는지에 대해서도 약간의 혼란이 있습니다." + +#. type: Plain text +#: documentation/content/en/articles/bsdl-gpl/_index.adoc:208 +msgid "" +"In another example, Red Hat purchased Cygnus, an engineering company that " +"had taken over development of the FSF compiler tools. Cygnus was able to do " +"so because they had developed a business model in which they sold support " +"for GNU software. This enabled them to employ some 50 engineers and drive " +"the direction of the programs by contributing the preponderance of " +"modifications. As Donald Rosenberg states \"projects using licenses like " +"the GPL...live under constant threat of having someone take over the project " +"by producing a better version of the code and doing it faster than the " +"original owners.\" <>" +msgstr "" +"또 다른 예로, 레드햇(Red Hat)은 FSF 컴파일러 도구 개발을 맡았던 엔지니어링 " +"회사인 시그너스(Cygnus)를 인수했습니다. 시그너스를 인수할 수 있었던 이유는 " +"이 회사가 GNU 소프트웨어에 대한 지원을 상품으로 판매하는 비즈니스 모델을 " +"개발했기 때문입니다. 이를 통해 약 50명의 엔지니어를 고용할 수 있었고, 수정 " +"사항을 주도적으로 제안하여 프로그램의 방향을 변경할 수 있었습니다. 도널드 " +"로젠버그(Donald Rosenberg)는 “GPL과 같은 라이선스를 사용하는 프로젝트는… " +"누군가 더 나은 버전의 코드를 만들어서 기존 소유자보다 더 빨리 프로젝트를 " +"장악할 수 있다는 끊임없는 위협에 시달리고 있다”고 말합니다. <>" + +#. type: Title == +#: documentation/content/en/articles/bsdl-gpl/_index.adoc:210 +#, no-wrap +msgid "GPL Advantages and Disadvantages" +msgstr "GPL의 장점과 단점" + +#. type: Plain text +#: documentation/content/en/articles/bsdl-gpl/_index.adoc:214 +msgid "" +"A common reason to use the GPL is when modifying or extending the gcc " +"compiler. This is particularly apt when working with one-off specialty CPUs " +"in environments where all software costs are likely to be considered " +"overhead, with minimal expectations that others will use the resulting " +"compiler." +msgstr "" +"GPL을 사용하는 일반적인 경우는 gcc 컴파일러를 수정하거나 확장할 때입니다. " +"이는 특히 모든 소프트웨어 비용이 오버헤드로 간주될 가능성이 높은 환경에서, " +"일회성으로 특수한 CPU로 작업할 때와 같이 아주 적은 수의 사람만이 변경된 " +"컴파일러를 사용하는 상황에 적합합니다." + +#. type: Plain text +#: documentation/content/en/articles/bsdl-gpl/_index.adoc:217 +msgid "" +"The GPL is also attractive to small companies selling CDs in an environment " +"where \"buy-low, sell-high\" may still give the end-user a very inexpensive " +"product. It is also attractive to companies that expect to survive by " +"providing various forms of technical support, including documentation, for " +"the GPLed intellectual property world." +msgstr "" +"GPL은 최종 사용자에게 매우 저렴한 제품을 제공하는 “박리다매” 환경에서 CD를 " +"판매하는 소규모 회사와 같은 곳에 매력적입니다. 또한 GPL이 적용된 지적 " +"재산권 세계에서 문서를 포함한 다양한 형태의 기술 지원을 제공함으로써 생존을 " +"기대하는 기업에게도 매력적입니다." + +#. type: Plain text +#: documentation/content/en/articles/bsdl-gpl/_index.adoc:220 +msgid "" +"A less publicized and unintended use of the GPL is that it is very favorable " +"to large companies that want to undercut software companies. In other " +"words, the GPL is well suited for use as a marketing weapon, potentially " +"reducing overall economic benefit and contributing to monopolistic behavior." +msgstr "" +"GPL을 따라 충분히 공개하지 않거나 의도치 않게 GPL을 사용하는 것은 소프트웨어 " +"회사를 약화시키려는 대기업에 매우 유리합니다. 즉, GPL은 마케팅 무기로 " +"사용하기에 적합하여 전반적인 경제적 이익을 감소시키고 독과점 행위에 기여할 " +"수 있습니다." + +#. type: Plain text +#: documentation/content/en/articles/bsdl-gpl/_index.adoc:223 +msgid "" +"The GPL can present a real problem for those wishing to commercialize and " +"profit from software. For example, the GPL adds to the difficulty a " +"graduate student will have in directly forming a company to commercialize " +"his research results, or the difficulty a student will have in joining a " +"company on the assumption that a promising research project will be " +"commercialized." +msgstr "" +"GPL은 소프트웨어를 상업화하여 수익을 창출하고자 하는 사람들에게 실질적인 " +"문제를 야기할 수 있습니다. 예를 들어, 대학원생이 자신의 연구 결과를 " +"상용화하기 위해 직접 회사를 설립하거나, 유망한 연구 프로젝트의 상용화를 " +"전제로 회사에 입사하는 데 GPL은 어려움을 가중시킬 수 있습니다." + +#. type: Plain text +#: documentation/content/en/articles/bsdl-gpl/_index.adoc:228 +msgid "" +"For those who must work with statically-linked implementations of multiple " +"software standards, the GPL is often a poor license, because it precludes " +"using proprietary implementations of the standards. The GPL thus minimizes " +"the number of programs that can be built using a GPLed standard. The GPL " +"was intended to not provide a mechanism to develop a standard on which one " +"engineers proprietary products. (This does not apply to Linux applications " +"because they do not statically link, rather they use a trap-based API.)" +msgstr "" +"여러 소프트웨어 표준의 정적연결로 구현되는 작업을 하는 사람들에게 GPL은 " +"표준의 독점적 구현을 사용할 수 없기 때문에 좋지 않은 라이선스인 경우가 " +"많습니다. 따라서 GPL은 GPL 표준을 사용하여 만들 수 있는 프로그램의 수를 " +"줄이는 결과를 낳았습니다. GPL은 독점적 제품을 개발하는 표준 메커니즘을 " +"제공하지 않기 때문입니다. (Linux 애플리케이션은 정적으로 링크하지 않고 트랩 " +"기반 API를 사용하기 때문에 적용되지 않습니다.)" + +#. type: Plain text +#: documentation/content/en/articles/bsdl-gpl/_index.adoc:232 +msgid "" +"The GPL attempts to make programmers contribute to an evolving suite of " +"programs, then to compete in the distribution and support of this suite. " +"This situation is unrealistic for many required core system standards, which " +"may be applied in widely varying environments which require commercial " +"customization or integration with legacy standards under existing (non-GPL) " +"licenses. Real-time systems are often statically linked, so the GPL and " +"LGPL are definitely considered potential problems by many embedded systems " +"companies." +msgstr "" +"GPL은 프로그래머들이 진화하는 프로그램 모음에 기여한 후, 이 모음 배포 및 " +"지원에 경쟁하도록 만듭니다. 이러한 상황은 상업적 커스터마이징이나 기존(non-" +"GPL) 라이선스에 따른 레거시 표준과의 통합이 필요한 매우 다양한 환경에 적용될 " +"수 있는, 많은 필수 핵심 시스템 표준에 대해서는 비현실적입니다. 실시간 " +"시스템은 정적으로 연결되는 경우가 많기 때문에 많은 임베디드 시스템 " +"회사에서는 GPL과 LGPL을 잠재적인 문제로 간주하고 있습니다." + +#. type: Plain text +#: documentation/content/en/articles/bsdl-gpl/_index.adoc:235 +msgid "" +"The GPL is an attempt to keep efforts, regardless of demand, at the research " +"and development stages. This maximizes the benefits to researchers and " *** 385 LINES SKIPPED *** From nobody Mon May 1 14:09:30 2023 X-Original-To: dev-commits-doc-all@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4Q94pL6Mtwz48b5C for ; Mon, 1 May 2023 14:09:30 +0000 (UTC) (envelope-from git@FreeBSD.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Q94pL5vNlz3Nvm; Mon, 1 May 2023 14:09:30 +0000 (UTC) (envelope-from git@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1682950170; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=6SUCAz13albVsrei61yKLFViGJZZ3f32iMPenOg2mjk=; b=x0GF4+G0KU0zsXJ1vlabt02JKu0ge/alC5Pg6Yd8/L8H+6rjRWaH6Waq2tvpKnBZNkrBj7 MOg5LN+z7TL4aWg7alYDEKOhwLbMulL2TC58zeiqD1mcG0Pahfa8Nky2Vt4w3C5AAdBA3V f9516Xv89ziLRVFqANd4uD02Gigg0PDoXtj7O4DPTfQWwvpvhM7iV0eIkMFiZ5T93uWZ0z AJHAryfum7/D4IGvSEhK3h2uF2Wf7rMdomEmQ9W/cjusg8ZWvO0GGi9R7j6j+aM9XFGDuA w942o1CAuPI6/qrHCBOFNqv/6gD7+1ww0690JZjzFVpdX617EL4fzExD3xCgrg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1682950170; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=6SUCAz13albVsrei61yKLFViGJZZ3f32iMPenOg2mjk=; b=pxqPzA/Fs8vqwv7G8613RacDAnu5DhmxzuGtgYQv42I3LeNBlvMiESDiA+Z69IYRL+17hW M6LUSbQTPAQi7Sxv9qnREvkhhpmovVxnB5jd5RMsOUxpMEj4NQ8ahZyYr4lXoiiyaXZQ2f /RRv8tiGua8Eokuv1thOIU58dlsJVUZbsXov/90m2elramMCgaGYwZ9NvgFk1JanSKdjKc /AaLLp6ym1n8GFpAnrCIJm4ZjeF+8r0mwxZTr1sK/+1Xs69P0wH8AAyQ2yLIn0ZEV4QFqF Y0mbK0WV5q58CzND/QVdp+vUzHzc/hnQtRQIavWeAHm+h07YIsEca4yo6HMObA== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1682950170; a=rsa-sha256; cv=none; b=MKbjnABAAqtIKQN2TgxDPoxfw+qdn4O2htiwevv3YGgXUGV7juVDxA+QwDohCaCWA6VvHN F1xqFn57luW1N7z2l6m0379Fza9SwNjApUThVNeY2y2DG9/WCEpBEi76fX6RaeXgH3nE2E 2/QW8GzVJGLtIM6J13rUwAHtGK8+7Hc9L0gDTLfK6QOXSyb7PSr7gt0W8zyOY5pOCIYcAz O5q1RlGoMnhPXqJXWAJMXbPUoEGK12t4N2HO8FiD5tq9pRVr+AY7chJM5WYPVkNUDkr5ZL 4gl3bOcI78xD+PjuprgiKL9+w0X6vhq+MwYY0afJuxQEn4/ld47Y+plRfqs1GA== Received: from gitrepo.freebsd.org (gitrepo.freebsd.org [IPv6:2610:1c1:1:6068::e6a:5]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 4Q94pL51VBz17cc; Mon, 1 May 2023 14:09:30 +0000 (UTC) (envelope-from git@FreeBSD.org) Received: from gitrepo.freebsd.org ([127.0.1.44]) by gitrepo.freebsd.org (8.16.1/8.16.1) with ESMTP id 341E9UE8057486; Mon, 1 May 2023 14:09:30 GMT (envelope-from git@gitrepo.freebsd.org) Received: (from git@localhost) by gitrepo.freebsd.org (8.16.1/8.16.1/Submit) id 341E9Us3057485; Mon, 1 May 2023 14:09:30 GMT (envelope-from git) Date: Mon, 1 May 2023 14:09:30 GMT Message-Id: <202305011409.341E9Us3057485@gitrepo.freebsd.org> To: doc-committers@FreeBSD.org, dev-commits-doc-all@FreeBSD.org From: "Danilo G. Baio" Subject: git: 089b9dfa46 - main - Cirrus CI: Use FreeBSD 13.2 image List-Id: Commit messages for all branches of the doc repository List-Archive: https://lists.freebsd.org/archives/dev-commits-doc-all List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-dev-commits-doc-all@freebsd.org X-BeenThere: dev-commits-doc-all@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Git-Committer: dbaio X-Git-Repository: doc X-Git-Refname: refs/heads/main X-Git-Reftype: branch X-Git-Commit: 089b9dfa469c233908c232049fe2a85ff17bbed2 Auto-Submitted: auto-generated X-ThisMailContainsUnwantedMimeParts: N The branch main has been updated by dbaio: URL: https://cgit.FreeBSD.org/doc/commit/?id=089b9dfa469c233908c232049fe2a85ff17bbed2 commit 089b9dfa469c233908c232049fe2a85ff17bbed2 Author: Danilo G. Baio AuthorDate: 2023-05-01 14:06:59 +0000 Commit: Danilo G. Baio CommitDate: 2023-05-01 14:06:59 +0000 Cirrus CI: Use FreeBSD 13.2 image Reported by: QWERTIOX Pull Request: https://github.com/freebsd/freebsd-doc/pull/177 --- .cirrus.yml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/.cirrus.yml b/.cirrus.yml index a924297df0..591b8e2676 100644 --- a/.cirrus.yml +++ b/.cirrus.yml @@ -1,5 +1,5 @@ freebsd_instance: - image_family: freebsd-13-1-snap + image_family: freebsd-13-2-snap env: CIRRUS_CLONE_DEPTH: 1 From nobody Mon May 1 18:16:36 2023 X-Original-To: dev-commits-doc-all@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4Q9BHT0s5Rz48qW3 for ; Mon, 1 May 2023 18:16:37 +0000 (UTC) (envelope-from git@FreeBSD.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Q9BHT0Kqtz4FVh; Mon, 1 May 2023 18:16:37 +0000 (UTC) (envelope-from git@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1682964997; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=PZLUc6aEKs0nZL7ZqQTAUyPtNGGQA0VLe7GwMY1sBkY=; b=G/qh4dEPbr/2l6jtzuBObwJ5FdSNdk1K37dMOmjjlMl/2pqAw2tdd/TyOuW+efd7aILvJ3 HmmpDWYHI29MeuOWAA0OqINjc9s5NbHlZqSaiEm7AT+sfR0rN7iWrQATgB3+3dGnnl41mK OALmz7MhY7XrRAd0Lt+NwSjJvZw8pttDp0II62Egl80CBRE19lWgiad/zVH0LRUowJ+Moi 9Qj0wluVPLd0XDz4l5PetBDmYQM5gxt3fSNpQQBZKqZElmvXQyjMb1p05k90gZ7JSOuK/Q L3omHHwuivZ4Bny6bKsT/lcqiAVgK/6vGvrOS1A0Ssx18HIzlC6ciwZeri5wPw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1682964997; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=PZLUc6aEKs0nZL7ZqQTAUyPtNGGQA0VLe7GwMY1sBkY=; b=X7/DH/VNaGkCvNof58hRx0SCxjxR4YJR6MyZSHKIKfZCiLcK9Wh9CRAhe1W18B74TsEabd rn0GvBp1xaar8X11EF6L0rtnyV9W42/UwWTbmqrperfYiqN6RzbLk8Yzl3KHQXp2hJ6b7h VW94fVl3/WyvMls9yt9QQYYP6cj2J1xFtXYJr9gqE6ES3iVRzADYFeodkczeIV/N6TjtpB xkfOWiUU5Rywv+58FP2fKu+FYnx6bKMuOXMs/aeuYZ7XeP+HfKnxYXZ2rSpUD9kfhcAhJ5 Gcszh++ML32dMv8J6zENgDW9Q8lTX10KH7fhOHnmpS3cjG6TVYHo8heryIllGg== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1682964997; a=rsa-sha256; cv=none; b=KqfYWTF24clE+49DT7F/0IxmzcCf2RURod0ynashddy0bJxqfbN3wdkynjYhm55nga6A6j hQUce2H2aprGJmyBknL9MktIEvVYZujVmT0bl7azy56JHjGvy3oseroNF8ro4+OwdiTpBR EDziOrmLRQgLqa7DJjhJr6cEhElj/NsJiVGQ+N0YeAiEHWUCrB3vDSzVdlge5O0Ttx10JA y+ixH9ro4SsSxI9tko96Fyt083i/T9rtSbJIHEWUfuj3rlfSJD1YFwC5ZW9SutDZucpT0d R+oA8VR54+6rQu5oE4xRF1oM/1nJY05Rr97jicgkOs/LcLKz5Kb6usn9WP0a3A== Received: from gitrepo.freebsd.org (gitrepo.freebsd.org [IPv6:2610:1c1:1:6068::e6a:5]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 4Q9BHS6T5CzGGp; Mon, 1 May 2023 18:16:36 +0000 (UTC) (envelope-from git@FreeBSD.org) Received: from gitrepo.freebsd.org ([127.0.1.44]) by gitrepo.freebsd.org (8.16.1/8.16.1) with ESMTP id 341IGaQO071112; Mon, 1 May 2023 18:16:36 GMT (envelope-from git@gitrepo.freebsd.org) Received: (from git@localhost) by gitrepo.freebsd.org (8.16.1/8.16.1/Submit) id 341IGaE7071111; Mon, 1 May 2023 18:16:36 GMT (envelope-from git) Date: Mon, 1 May 2023 18:16:36 GMT Message-Id: <202305011816.341IGaE7071111@gitrepo.freebsd.org> To: doc-committers@FreeBSD.org, dev-commits-doc-all@FreeBSD.org From: Glen Barber Subject: git: fcf1835fea - main - 14.0 schedule: the KBI freeze and main slush are delayed List-Id: Commit messages for all branches of the doc repository List-Archive: https://lists.freebsd.org/archives/dev-commits-doc-all List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-dev-commits-doc-all@freebsd.org X-BeenThere: dev-commits-doc-all@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Git-Committer: gjb X-Git-Repository: doc X-Git-Refname: refs/heads/main X-Git-Reftype: branch X-Git-Commit: fcf1835fea34b1fd90ecf1fee1ae45583f9284dc Auto-Submitted: auto-generated X-ThisMailContainsUnwantedMimeParts: N The branch main has been updated by gjb: URL: https://cgit.FreeBSD.org/doc/commit/?id=fcf1835fea34b1fd90ecf1fee1ae45583f9284dc commit fcf1835fea34b1fd90ecf1fee1ae45583f9284dc Author: Glen Barber AuthorDate: 2023-05-01 18:16:01 +0000 Commit: Glen Barber CommitDate: 2023-05-01 18:16:01 +0000 14.0 schedule: the KBI freeze and main slush are delayed Sponsored by: Rubicon Communications, LLC ("Netgate") --- website/content/en/releases/14.0R/schedule.adoc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/website/content/en/releases/14.0R/schedule.adoc b/website/content/en/releases/14.0R/schedule.adoc index cc89629a15..bd449139ce 100644 --- a/website/content/en/releases/14.0R/schedule.adoc +++ b/website/content/en/releases/14.0R/schedule.adoc @@ -34,7 +34,7 @@ Announcements regarding the availability of the ALPHA snapshots will be sent to |Action |Expected |Actual |Description |Initial release schedule announcement |- |19 August 2022 |Release Engineers send announcement email to developers with a rough schedule. |Release schedule reminder |17 April 2023|17 April 2023 |Release Engineers send reminder announcement e-mail to developers with updated schedule. -|Code slush begins / KBI freeze |25 April 2023 |- |Release Engineers announce that all further commits to the {localBranchHead} branch will not require explicit approval, however new features should be avoided. Additionally, there can be no changes to the KBI until {localBranchHead} is branched to {localBranchStable}. +|Code slush begins / KBI freeze |25 April 2023 |delayed |Release Engineers announce that all further commits to the {localBranchHead} branch will not require explicit approval, however new features should be avoided. Additionally, there can be no changes to the KBI until {localBranchHead} is branched to {localBranchStable}. |{localBranchStable} branch |12 May 2023 |- |{localBranchStable} branch created; release engineering continues on this branch. |{localBranchReleng} branch |26 May 2023 |- |{localBranchReleng} branch created; future release engineering proceeds on this branch. Commits to this branch require explicit approval from the Release Engineers. |BETA1 builds begin |26 May 2023 |- |First beta test snapshot. From nobody Tue May 2 02:53:30 2023 X-Original-To: dev-commits-doc-all@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4Q9Plt3w72z48Lcf for ; Tue, 2 May 2023 02:53:30 +0000 (UTC) (envelope-from git@FreeBSD.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Q9Plt2HzDz49fy; Tue, 2 May 2023 02:53:30 +0000 (UTC) (envelope-from git@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1682996010; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=c+IzjDItaB+6g8tVAz2z35pN38B/GK3PhEB0sQxuQSg=; b=F4jTAUVFJ/eqyOh/mtvg7dS6WPcsAZ29sBOlvn7W2LEbRqtInZYlygV+ynIGEQa6idOiYg V8Of0XqaNwtBgtUSpXlaMvX3iXRBC2s1ryTTKjPHECMFfTG3IYA4VBo4ydL1kUDQ55Usyc lc+lusawHpOtgPwbx7e5b3hsAltUsK6EHPyimJaeAEVf2+kwzDZH9nJF0rIS2VusI9xqo5 5Ob2RqGaKdUxC6mv2lBhnMyE2S30nSv4bqAZT36STLAmZIA9GcvJHlLGWxsAwMSzB1ijEi zD8pFO1nw87MlDBr+rcoDsPzA2uX4CxFTNkaXJs1mj/EHHmf8NfIAaf0v1VfDw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1682996010; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=c+IzjDItaB+6g8tVAz2z35pN38B/GK3PhEB0sQxuQSg=; b=mJMhXImcH3mR8B1PdpZas4w5ZCXBSx7WS5WunEETHFLms/QuANltNW+9KpyFixVgMVPenO JtE7Ah1A5nZ/JjoKQkFqW6zf+Os2EiB7ZxbKu738ZfhLFa0DEwoETWNjzkMMIZZGqIwMN1 vzl0Cks1D3987u+RNQKBlcf2WGbg8qCvG9Zt+UhKa01UMypY7AF/r4/ZA6POaofoqeNQE9 3nRydpsF8RT+9kqSRJcYdMfIVd3Xx7jhHWbL5T63QVr8/ah+9u5RLEKECZ3Ayz7KX98kkq LZkRYban5hAqWv4dFY7QRJI73I+cggX1nm4U7L+IUMyzodgbjstwJxm2xJrjEw== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1682996010; a=rsa-sha256; cv=none; b=ZB6qjRA15AnxovMpZe+39EeHpZthBd6cVirkDlP3HvBWdj7CMh5sz71bHfxdK2WVD4NpSd byPEb7DmkctjfyAfXioGb09KkFAt+BCvDZZNGnnipZYhQuF3yoaCmkISqzWpCrgNEqm8VM D1ryCURUTL0KnLjNEp1Xe0WFHdPC5YaQV0b4cP+EpUyKGLfr29zO3x0AILR3yvwJf8omcN 2dl+ggarewQWtVCdTJHcRDbvvyRh5rtBoxJ8xyJGpBXIb8HFS3lEq4R/VULbCrRLJLJJCG Mq+DyGVLNsCcPvzMQu3K2gSNoLyjlJUD7HckT+8N+jly3mE6eFzhxqREeF6l6A== Received: from gitrepo.freebsd.org (gitrepo.freebsd.org [IPv6:2610:1c1:1:6068::e6a:5]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 4Q9Plt142HzWbK; Tue, 2 May 2023 02:53:30 +0000 (UTC) (envelope-from git@FreeBSD.org) Received: from gitrepo.freebsd.org ([127.0.1.44]) by gitrepo.freebsd.org (8.16.1/8.16.1) with ESMTP id 3422rUon028685; Tue, 2 May 2023 02:53:30 GMT (envelope-from git@gitrepo.freebsd.org) Received: (from git@localhost) by gitrepo.freebsd.org (8.16.1/8.16.1/Submit) id 3422rU7T028684; Tue, 2 May 2023 02:53:30 GMT (envelope-from git) Date: Tue, 2 May 2023 02:53:30 GMT Message-Id: <202305020253.3422rU7T028684@gitrepo.freebsd.org> To: doc-committers@FreeBSD.org, dev-commits-doc-all@FreeBSD.org From: Philip Paeps Subject: git: c4cf26bd18 - main - Annual update of my PGP key expiry date. List-Id: Commit messages for all branches of the doc repository List-Archive: https://lists.freebsd.org/archives/dev-commits-doc-all List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-dev-commits-doc-all@freebsd.org X-BeenThere: dev-commits-doc-all@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Git-Committer: philip X-Git-Repository: doc X-Git-Refname: refs/heads/main X-Git-Reftype: branch X-Git-Commit: c4cf26bd18701ab459ce7047a3a5869e13c2a1e1 Auto-Submitted: auto-generated X-ThisMailContainsUnwantedMimeParts: N The branch main has been updated by philip: URL: https://cgit.FreeBSD.org/doc/commit/?id=c4cf26bd18701ab459ce7047a3a5869e13c2a1e1 commit c4cf26bd18701ab459ce7047a3a5869e13c2a1e1 Author: Philip Paeps AuthorDate: 2023-05-02 02:53:01 +0000 Commit: Philip Paeps CommitDate: 2023-05-02 02:53:01 +0000 Annual update of my PGP key expiry date. --- documentation/static/pgpkeys/philip.key | 42 ++++++++++++++++----------------- 1 file changed, 21 insertions(+), 21 deletions(-) diff --git a/documentation/static/pgpkeys/philip.key b/documentation/static/pgpkeys/philip.key index 544f9295a3..36a28015bd 100644 --- a/documentation/static/pgpkeys/philip.key +++ b/documentation/static/pgpkeys/philip.key @@ -2,13 +2,13 @@ [.literal-block-margin] .... -pub ed25519/BB6D8A14AFE7D96B 2021-05-25 [SC] [expires: 2024-07-01] +pub ed25519/BB6D8A14AFE7D96B 2021-05-25 [SC] [expires: 2025-07-01] Key fingerprint = B851 CD3A C248 F2ED 3E2C C18C BB6D 8A14 AFE7 D96B uid Philip Paeps uid Philip Paeps -sub ed25519/D92733BA06C579C2 2021-05-25 [S] [expires: 2023-07-01] -sub cv25519/235A60C6046F82F9 2021-05-25 [E] [expires: 2023-07-01] -sub ed25519/252E8C8E533D50C5 2021-05-25 [A] [expires: 2023-07-01] +sub ed25519/D92733BA06C579C2 2021-05-25 [S] [expires: 2024-07-01] +sub cv25519/235A60C6046F82F9 2021-05-25 [E] [expires: 2024-07-01] +sub ed25519/252E8C8E533D50C5 2021-05-25 [A] [expires: 2024-07-01] .... @@ -19,26 +19,26 @@ sub ed25519/252E8C8E533D50C5 2021-05-25 [A] [expires: 2023-07-01] mDMEYKyY8hYJKwYBBAHaRw8BAQdAIXiSTuKHgUIE2Zjco63bMMvb4pJ305MmoUyP uaiIqfS0IFBoaWxpcCBQYWVwcyA8cGhpbGlwQHRyb3VibGUuaXM+iJ0EExYKAEUC GwMFCwkIBwIDIgIBBhUKCQgLAgQWAgMBAh4HAheAAhkBFiEEuFHNOsJI8u0+LMGM -u22KFK/n2WsFAmJvkHcFCQXWAU4ACgkQu22KFK/n2WvFqQEAu2kViu2eEF2lzri3 -doEOpmnUWrS8Qy8eRgdYQzWfBnoBAOBXPmiPnSOUv+dxVVu0+T5YxFwq4a/Hu2OB -a/rqHPoDtCFQaGlsaXAgUGFlcHMgPHBoaWxpcEBmcmVlYnNkLm9yZz6ImgQTFgoA +u22KFK/n2WsFAmRQd+0FCQe3NNAACgkQu22KFK/n2WvWSwEA3wwILfXGZuSTRMJl +CfT/6Km4dG+d90eQGW1gISWdrQEA/Rgja3aE64RxQVGuRCfCo5YKyEwRQONCexKY +t1bk3I0NtCFQaGlsaXAgUGFlcHMgPHBoaWxpcEBmcmVlYnNkLm9yZz6ImgQTFgoA QgIbAwULCQgHAgMiAgEGFQoJCAsCBBYCAwECHgcCF4AWIQS4Uc06wkjy7T4swYy7 -bYoUr+fZawUCYm+QhAUJBdYBTgAKCRC7bYoUr+fZa1wiAQCNVnLsfoEan63YOjAV -HkqIpotxVOlGEsUTC/wQxX+cbAD/ZkuBCZwJs/7pUscP3jBkdoY5DvyQV5vYYcXw -LJYWcAG4MwRgrJlsFgkrBgEEAdpHDwEBB0AjN6sanKZplYEZ1REyb02vMSIfg7Jh -9uNF4i72RdAX94j1BBgWCgAmAhsCFiEEuFHNOsJI8u0+LMGMu22KFK/n2WsFAmJv -kKQFCQPze9YAgXYgBBkWCgAdFiEEkJ1LuRY1fuOXdPQB2SczugbFecIFAmCsmWwA +bYoUr+fZawUCZFB4AwUJB7c00AAKCRC7bYoUr+fZawDJAP4ovNM+GHmpTsD/2nOX +8eWCdYRzjSdl9f1BG2kDF2hGugEAiEeT+b67lrgMJh0sCFEcU03MDqOzylu9BqeV +qgD6kwu4MwRgrJlsFgkrBgEEAdpHDwEBB0AjN6sanKZplYEZ1REyb02vMSIfg7Jh +9uNF4i72RdAX94j1BBgWCgAmAhsCFiEEuFHNOsJI8u0+LMGMu22KFK/n2WsFAmRQ +eCoFCQXWANwAgXYgBBkWCgAdFiEEkJ1LuRY1fuOXdPQB2SczugbFecIFAmCsmWwA CgkQ2SczugbFecLiHQD+KWkaHCz15F2NKuhWVSDaW2EL2T8osDEBupPsxxpVI2wB -AMwLYIjuMhF7W8nzU637j/ThD+DQKXkkWRu9gIKPkZYGCRC7bYoUr+fZa2ALAP94 -2/sq2+NEmgg52OnhryyyTotCdW6X30Nu0hsrOVxaEgEA1WpxQgUHhe2U2DfWhOz+ -LSvFx++uLXBbHg12LcUFwQm4OARgrJmDEgorBgEEAZdVAQUBAQdA43q+QOECkVQn +AMwLYIjuMhF7W8nzU637j/ThD+DQKXkkWRu9gIKPkZYGCRC7bYoUr+fZay+dAPsF +NKFb3GEgAFkETaCy/5pSqYGYfIoRqifRW0lXQYPVJAEArTYW5K8C0IJdUtVPDQBZ +TwDYlIMgKqbIyR04c+MPiQq4OARgrJmDEgorBgEEAZdVAQUBAQdA43q+QOECkVQn PcmLuM1+ToWo4vVeU3K+yOjABDtsOxkDAQgHiH4EGBYKACYCGwwWIQS4Uc06wkjy -7T4swYy7bYoUr+fZawUCYm+QswUJA/N7vwAKCRC7bYoUr+fZaw5sAQCC+hoi3Wn1 -MYdfiadgphIUMg2h60Bn4EKD+2axfeY8WgEAsSYmXbKHWL95Q5d6luFG937R+QS3 -uDZYcsbzGuVHAQK4MwRgrJmVFgkrBgEEAdpHDwEBB0BZL2Zkanycm9ZxXyblVkJY +7T4swYy7bYoUr+fZawUCZFB4KgUJBdYAxQAKCRC7bYoUr+fZa4+EAQCLSSE1PzK8 +XnsALdCrE4ZZTPiDA7lZckakLCsd1Cd6EQEAyb7w8quncxNJTstvMg70iAsbb+0i +nXEFNpEW85fSkQ+4MwRgrJmVFgkrBgEEAdpHDwEBB0BZL2Zkanycm9ZxXyblVkJY 7uftl1+DtY4cCF/mP8K21Yh+BBgWCgAmAhsgFiEEuFHNOsJI8u0+LMGMu22KFK/n -2WsFAmJvkMMFCQPze60ACgkQu22KFK/n2WsmhQEA3qZn7MtCwTIH9sGXRMVoyWbk -q3ad71afC4pgpnP0PxUBAJ/882JTllFCsnIJtAoz+uxwrpjo/iImyIK/toioJh4B -=GHHY +2WsFAmRQeCoFCQXWALMACgkQu22KFK/n2Wt/3AEAhnSkKER2XnzihDsmhDnn2Nol +xvnOPgLJ/iIavt/xHfwA/30GRshX3NpVLTMEOzNmyFTXQuBYQP718a6YgivKNBwG +=6t2q -----END PGP PUBLIC KEY BLOCK----- .... From nobody Tue May 2 20:57:04 2023 X-Original-To: dev-commits-doc-all@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4Q9sp928pVz49PHL for ; Tue, 2 May 2023 20:57:05 +0000 (UTC) (envelope-from git@FreeBSD.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Q9sp90jfMz4Lmn; Tue, 2 May 2023 20:57:05 +0000 (UTC) (envelope-from git@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1683061025; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=xWP6u1D+V5DMpQZ/pCgC0CAlip2cpqVEyZkq+1xuEbU=; b=QxurdVGGfqkslIPwbbl0+pEnR+ujKLikBTvJD3GJaJWpkk5CR1UdcXNr1e0tVhOYLNu8ge LQxT2MCIeAP/1hjxUPuDr4o2PRlEqza+apJfRjoDfcLndd/1odFMxT7f6XaR3mVQtenf50 rgWbHnv1xaXvcLRUyKnFY9UVWOgJE2zgzvFqop4DEOoTZknU8F9sV9+e/9Z743hnk0LmBW GOxKSclKOb1lJLHyqrisPL3MvbssIzENRoQzNITY+4mJG/Znj028dN60eTvSKNu8k+nySv yHwK1/X5IN/yJwRL7ne7+N/56Ija225BNWCqe6Bec5UsId+NejBFwjuu8nMDEA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1683061025; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=xWP6u1D+V5DMpQZ/pCgC0CAlip2cpqVEyZkq+1xuEbU=; b=lPspCkcaqnOybX3QKYEt/g7XO6wRbAExT73tDIShRWXS6KGq0AXfWGXx4OqvS0cGUeVBCm CvLC9HTQzs5/LxJmA2U78+hsZU6FBFsbkPw7v0S1XKQ9jxZWH105a39plgd1V8IcR+CR/n LHW+yjiQpDZb3AM+3S1dzDN5TSqCt9gjhBlGKHDj+yd3U2NqkaWmyP5037JP8cNP4x4i0/ D7+5v6ZP2IHmWP4GJBd2MIs6h3sSDJxUEXMt+D+d9tLItwjEfZ5eeyXoz+Mc9JSeLERAv/ 9boz69gWmGVZyzy+wDoRwSlLdT4dMDcu27i1nd3dVx2neOyQ+fmq6YexNrpzbw== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1683061025; a=rsa-sha256; cv=none; b=o9TyEJDNydL9WlPtpb3VmjG4zldCEbvYSUmAjcKikHmOw32X2MAYxUh3DK3ksHo9ERDCPH Wi9BG1sMLUt3YL9WHTbCUFPIkmD1oCRHqFfi2M6LEsPO2vzG4Ltw0Dn4nPl6fexcK9gb5+ H42BSW/LE2nSIv8qGeY9CoG/V9+LvC1AxH9Q6VnijtRAghO17zYDYVQSh/sseutpsDC63J 2jF4cgxT2bPTQCP74karXslFEaFbl9UfRfW4Rs9BQGyxrGeB/x/hjbrlpA3MlfKQWFY5jO ThH0T9UMQpchppr4MsIvBbh88x43SgVeCvyIQvpLuglamYRpgIoQG9BxHGHTzQ== Received: from gitrepo.freebsd.org (gitrepo.freebsd.org [IPv6:2610:1c1:1:6068::e6a:5]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 4Q9sp86w5Yz13HT; Tue, 2 May 2023 20:57:04 +0000 (UTC) (envelope-from git@FreeBSD.org) Received: from gitrepo.freebsd.org ([127.0.1.44]) by gitrepo.freebsd.org (8.16.1/8.16.1) with ESMTP id 342Kv41n024607; Tue, 2 May 2023 20:57:04 GMT (envelope-from git@gitrepo.freebsd.org) Received: (from git@localhost) by gitrepo.freebsd.org (8.16.1/8.16.1/Submit) id 342Kv4mK024606; Tue, 2 May 2023 20:57:04 GMT (envelope-from git) Date: Tue, 2 May 2023 20:57:04 GMT Message-Id: <202305022057.342Kv4mK024606@gitrepo.freebsd.org> To: doc-committers@FreeBSD.org, dev-commits-doc-all@FreeBSD.org From: Edson Brandi Subject: git: 83d19f9db7 - main - Article fonts translated to pt_BR and synced with doc tree version 98c736dd127a2096dc08252d1082300f2ec28ab5 List-Id: Commit messages for all branches of the doc repository List-Archive: https://lists.freebsd.org/archives/dev-commits-doc-all List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-dev-commits-doc-all@freebsd.org X-BeenThere: dev-commits-doc-all@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Git-Committer: ebrandi X-Git-Repository: doc X-Git-Refname: refs/heads/main X-Git-Reftype: branch X-Git-Commit: 83d19f9db770ae5752f7eedb16a502a07af5fe50 Auto-Submitted: auto-generated X-ThisMailContainsUnwantedMimeParts: N The branch main has been updated by ebrandi: URL: https://cgit.FreeBSD.org/doc/commit/?id=83d19f9db770ae5752f7eedb16a502a07af5fe50 commit 83d19f9db770ae5752f7eedb16a502a07af5fe50 Author: Edson Brandi AuthorDate: 2023-05-02 20:56:20 +0000 Commit: Edson Brandi CommitDate: 2023-05-02 20:56:20 +0000 Article fonts translated to pt_BR and synced with doc tree version 98c736dd127a2096dc08252d1082300f2ec28ab5 --- .../content/pt-br/articles/fonts/_index.adoc | 281 ++-- .../content/pt-br/articles/fonts/_index.po | 1615 ++++++++++++++++++++ 2 files changed, 1756 insertions(+), 140 deletions(-) diff --git a/documentation/content/pt-br/articles/fonts/_index.adoc b/documentation/content/pt-br/articles/fonts/_index.adoc index b7ad32c1c0..d15ac65a85 100644 --- a/documentation/content/pt-br/articles/fonts/_index.adoc +++ b/documentation/content/pt-br/articles/fonts/_index.adoc @@ -1,9 +1,12 @@ --- -title: Fontes e FreeBSD -subtitle: Um Tutorial authors: - - author: Dave Bodenstab + - + author: 'Dave Bodenstab' email: imdave@synet.net +description: 'Uma descrição das diversas tecnologias de fontes no FreeBSD e como usá-las com diferentes programas' +subtitle: 'A Tutorial' +tags: ["Fonts", "syscons", "X11", "Ghostscript", "Groff", "guide", "tutorial", "FreeBSD"] +title: 'Fontes e FreeBSD' trademarks: ["freebsd", "adobe", "apple", "linux", "microsoft", "opengroup", "general"] --- @@ -41,7 +44,7 @@ endif::[] [.abstract-title] Resumo -Este documento contém a descrição de vários arquivos de fontes que podem ser usados no FreeBSD e no driver do console do sistema, X11, Ghostscript e Groff. Manuais passo-a-passo são fornecidos para alterar a exibição do console do sistema para o modo 80x60, e para usar fontes tipo 1 com os aplicativos acima. +Este documento contém uma descrição dos vários arquivos de fontes que podem ser usados com o FreeBSD e o driver syscons, X11, Ghostscript e Groff. Exemplos de receitas são fornecidos para alternar o display syscons para o modo 80x60 e para usar fontes type 1 com os programas de aplicativos mencionados acima. ''' @@ -50,21 +53,21 @@ toc::[] [[intro]] == Introdução -Existem muitas origens de fontes disponíveis, e alguém pode questionar como elas podem ser utilizadas no FreeBSD. A resposta pode ser encontrada numa busca cuidadosa na documentação do componente onde você gostaria de utilizar a mesma. Isto pode consumir um bom tempo, portanto esse tutorial é uma tentativa de fornecer um atalho para outros que possam estar interessados. +Existem muitas fontes disponíveis e alguém pode perguntar como usá-las com o FreeBSD. A resposta pode ser encontrada pesquisando cuidadosamente a documentação do componente que deseja utilizar. Isso pode ser muito demorado, portanto, este tutorial é uma tentativa de fornecer um atalho para outras pessoas interessadas. [[terminology]] == Terminologia Básica -Existem muitos formatos diferentes de fontes e sufixos de arquivos de fontes associados. Alguns deles serão abordados aqui: +Existem muitos formatos diferentes de fontes e sufixos de arquivos de fontes associados. Alguns que serão abordados aqui são: [.filename]#.pfa#, [.filename]#.pfb#:: -PostScript(R) fonte tipo 1. O [.filename]#.pfa# é o formato __A__scii e o [.filename]#.pfb# é o formato __B__inário . +Fontes PostScript(R) type 1. O arquivo [.filename]#.pfa# é a forma __A__scii e o arquivo [.filename]#.pfb# é a forma __B__inária. [.filename]#.afm#:: -As métricas da fonte associado com a fonte tipo 1. +As métricas da fonte associado com a fonte type 1. [.filename]#.pfm#:: -As métricas da fonte para impressora associadas com a fonte tipo 1. +As métricas da fonte para impressora associadas com a fonte type 1. [.filename]#.ttf#:: Uma fonte TrueType(R) @@ -73,14 +76,14 @@ Uma fonte TrueType(R) Uma referência indireta para uma fonte TrueType (não é realmente uma fonte) [.filename]#.fon#, [.filename]#.fnt#:: -Fontes de tela bitmap +Fontes de tela bitmapped -O arquivo [.filename]#.fot# é usado pelo Windows(R) como um tipo de link simbólico para o arquivo de fonte TrueType(R) ([.filename]#.ttf#). Os arquivos de fonte [.filename]#.fon# também são utilizados no Windows. Eu desconheço uma maneira de utilizar essa fonte no FreeBSD. +O arquivo [.filename]#.fot# é usado pelo Windows(R) como um tipo de link simbólico para o arquivo de fonte TrueType(R) real ([.filename]#.ttf#). Os arquivos de fonte [.filename]#.fon# também são usados pelo Windows. Não conheço uma maneira de usar esse formato de fonte no FreeBSD. [[font-formats]] == Quais Formatos de Fonte eu Posso Utilizar? -Qual formato de arquivo de fonte é útil depende do aplicativo que está sendo usado. O FreeBSD por si só, não usa fontes. Aplicativos e/ou drivers podem fazer uso de arquivos de fontes. Aqui tem uma pequena referência cruzada de aplicação/driver para os sufixos de tipo de fonte: +O formato de arquivo de fonte mais adequado depende do aplicativo utilizado. O FreeBSD por si só não utiliza fontes. Programas de aplicativos e/ou drivers podem fazer uso dos arquivos de fonte. Aqui está uma pequena referência cruzada de aplicativos/drivers para os sufixos de tipo de fonte: Driver:: @@ -90,7 +93,7 @@ vt::: syscons::: [.filename]#.fnt# -Aplicativo:: +Aplicação:: Ghostscript::: [.filename]#.pfa#, [.filename]#.pfb#, [.filename]#.ttf# @@ -104,28 +107,28 @@ Groff::: Povray::: [.filename]#.ttf# -O sufixo [.filename]#.fnt# é frequentemente utilizado. Suspeito que, sempre que alguém quisesse criar um arquivo de fonte especializado para seu aplicativo, na maioria das vezes eles escolhiam esse sufixo. Então, é provável que os arquivos com esse sufixo não tenham o mesmo formato; Especificamente, os arquivos [.filename]#.fnt# usados pelo console do sistema do FreeBSD pode não ser do mesmo formato que o arquivo [.filename]#.fnt# encontrado no ambiente MS-DOS(R)/Windows(R). Não fiz nenhuma tentativa de utilizar outro arquivo [.filename]#.fnt# senão aquele fornecido com o FreeBSD. +O sufixo [.filename]#.fnt# é bastante utilizado. Eu suspeito que sempre que alguém quisesse criar um arquivo de fonte especializado para seu aplicativo, na maioria das vezes escolhia esse sufixo. Portanto, é provável que os arquivos com esse sufixo não sejam todos do mesmo formato; especificamente, os arquivos [.filename]#.fnt# usados pelo syscons no FreeBSD podem não ser do mesmo formato que um [.filename]#.fnt# encontrado no ambiente MS-DOS(R)/Windows(R). Não fiz nenhuma tentativa de usar outros arquivos [.filename]#.fnt# além daqueles fornecidos com o FreeBSD. [[virtual-console]] == Configurando um Console Virtual para o Modo de Linhas 80x60 -Primeiro, uma fonte 8x8 deve ser carregada. Para fazer isso, [.filename]#/etc/rc.conf# deve conter a linha (altere o nome da fonte para uma apropriada para a sua região): +Primeiramente, uma fonte 8x8 deve ser carregada. Para isso, o arquivo [.filename]#/etc/rc.conf# deve conter a linha (mude o nome da fonte para um apropriado para sua localização): [.programlisting] .... -font8x8="iso-8x8" # font 8x8 from /usr/shared/syscons/fonts/* (or NO). +font8x8="iso-8x8" # font 8x8 from /usr/share/syscons/fonts/* (or NO). .... -O comando para alterar o modo é man:vidcontrol[1]: +O comando para realmente mudar o modo é man:vidcontrol[1]: -[source,shell] +[source, shell] .... % vidcontrol VGA_80x60 .... -Vários programas orientados à tela, como o man:vi[1], devem ser capazes de determinar a dimensão corrente da tela. Como isto é conseguido através de uma chamada do `ioctl` para o driver do console (tal como o man:syscons[4]) ele irá determinar corretamente as dimensões da nova tela. +Vários programas orientados a tela, como man:vi[1], devem ser capazes de determinar as dimensões atuais da tela. Como isso é alcançado por meio de chamadas `ioctl` para o driver do console (como man:syscons[4]), eles determinarão corretamente as novas dimensões da tela. -Para fazer isso de uma maneira mais integrada, é possível incluir esses comandos nos scripts de inicialização de modo que ocorra quando o sistema for iniciado. Para fazer isso basta adicionar essa linha no [.filename]#/etc/rc.conf# +Para tornar isso mais contínuo, é possível incorporar esses comandos nos scripts de inicialização para que ocorram durante a inicialização do sistema. Para fazer isso, adicione esta linha ao arquivo [.filename]#/etc/rc.conf#. [.programlisting] .... @@ -135,29 +138,31 @@ allscreens_flags="VGA_80x60" # Set this vidcontrol mode for all virtual screens Referências: man:rc.conf[5], man:vidcontrol[1]. [[type1-fonts-x11]] -== Usando Fontes Type 1 com X11 +== Usando fontes Type 1 com o X11 -O X11 pode tanto usar o formato [.filename]#.pfa# quanto o formato [.filename]#.pfb# de fonte. As fontes do X11 estão localizadas em vários subdiretórios abaixo do [.filename]#/usr/X11R6/lib/X11/fonts#. Cada arquivo de fonte é uma referência cruzada do seu nome X11 com o conteúdo dos arquivos [.filename]#fonts.dir# em cada diretório. +O X11 pode usar fontes em formato [.filename]#.pfa# ou [.filename]#.pfb#. As fontes X11 estão localizadas em vários subdiretórios em [.filename]#/usr/X11R6/lib/X11/fonts#. Cada arquivo de fonte é cruzado com seu nome X11 pelos conteúdos de [.filename]#fonts.dir# em cada diretório. -Já existe um diretório chamado [.filename]#Type1#. A forma mais direta de adicionar uma nova fonte é colocá-la nesse diretório. Uma forma melhor seria colocar todas as novas fontes num diretório separado e usar um link simbólico para as fontes adicionais. Isso permite identificar as fontes sem confundir com aquelas que são originalmente fornecidas. Por exemplo: +Já existe um diretório chamado [.filename]#Type1#. A maneira mais direta de adicionar uma nova fonte é colocá-la neste diretório. Uma maneira melhor é manter todas as novas fontes em um diretório separado e usar um link simbólico para a fonte adicional. Isso permite que você mantenha um controle mais fácil das suas fontes sem confundir com as fontes fornecidas originalmente. Por exemplo: -[source,shell] +[source, shell] .... -Cria um diretório para armazenar os arquivos de fonte -% mkdir -p /usr/local/shared/fonts/type1 -% cd /usr/local/shared/fonts/type1 +Crie um diretório para conter os arquivos de fonte +% mkdir -p /usr/local/share/fonts/type1 +% cd /usr/local/share/fonts/type1 -Coloque os arquivos .pfa, .pfb and .afm aqui -Pode-se querer manter os arquivos readme, e outras documentações -para as fontes aqui +Coloque aqui os arquivos .pfa, .pfb e .afm + +Pode ser desejável manter arquivos readme e outras documentações + +para as fontes aqui também % cp /cdrom/fonts/atm/showboat/showboat.pfb . % cp /cdrom/fonts/atm/showboat/showboat.afm . -Mantenha um índice para a referência cruzada das fontes +Mantenha um índice para cruzar as fontes de referência. % echo showboat - InfoMagic CICA, Dec 1994, /fonts/atm/showboat >>INDEX .... -Agora, para usar a nova fonte com o X11, deve-se tornar os arquivos de fonte disponíveis e atualizados. Os nomes de fontes do X11 se parecem com: +Agora, para usar uma nova fonte com o X11, é necessário tornar o arquivo de fonte disponível e atualizar os arquivos de nome de fonte. Os nomes das fontes X11 se parecem com: [.programlisting] .... @@ -174,9 +179,9 @@ Agora, para usar a nova fonte com o X11, deve-se tornar os arquivos de fonte dis foundry family weight slant width additional style .... -Um novo nome precisa ser criado para cada nova fonte. Se você possui alguma informação na documentação que acompanha a fonte, então isso pode servir de base para a criação do nome. Se não há informação, então você pode ter alguma idéia usando man:strings[1] no arquivo da fonte. Por exemplo: +Um novo nome precisa ser criado para cada nova fonte. Se você tiver alguma informação da documentação que acompanha a fonte, ela pode servir como base para criar o nome. Se não houver informações disponíveis, você pode ter uma ideia usando o comando man:strings[1] no arquivo de fonte. Por exemplo: -[source,shell] +[source, shell] .... % strings showboat.pfb | more %!FontType1-1.0: Showboat 001.001 @@ -207,7 +212,7 @@ end readonly def Usando essas informações, um possível nome poderia ser: -[source,shell] +[source, shell] .... -type1-Showboat-medium-r-normal-decorative-0-0-0-0-p-0-iso8859-1 .... @@ -215,44 +220,45 @@ Usando essas informações, um possível nome poderia ser: Os componentes do nosso nome são: Companhia:: -Vamos nomear todas as novas fontes como `type1`. +Vamos apenas nomear todas as novas fontes como `type1`. Família:: -O nome da fonte +O nome da fonte. Densidade:: -Normal, negrito, média, semi-negrito, etc. Pelas informações acima do man:strings[1], essa fonte aparenta ter uma densidade __média__. +Normal, negrito (bold), médio (medium), seminegrito (semibold), etc. Pelos resultados do comando man:strings[1] mostrados acima, parece que esta fonte tem um peso __médio__ (medium). Inclinação:: -__r__oman, __i__tálico, __o__blíquo, etc. Como o _Ângulo Itálico_ é zero, o _roman_ será utilizado. +__r__omano (roman), __i__talico (italic), __o__blíquo (oblique), etc. Já que o ângulo de itálico (_ItalicAngle_) é zero, será usada a versão romana (_roman_). Largura:: -Normal, ampla, condensada, estendida, etc. Até que possa ser examinada, supomos que será __normal__. +Normal, ampla (wide), condensada (condensed), estendida (extended), etc. Até que possa ser examinada, a suposição será de que a fonte é __normal__. Estilo Adicional:: Frequentemente omitido, mas isso indicará que a fonte possui letras maiúsculas decorativas. Espaçamento:: -proporcional ou monoespaçada. A opção _Poporcional_ é usada quando o _isFixedPitch_ é falso. +Proporcional (proportional) ou espaçamento fixo (monospaced). Será usada a versão _proporcional_, já que o valor de _isFixedPitch_ é falso. -Todos esses nomes são arbitrários, mas deve-se tentar ser compatível com as convenções existentes. A fonte é referenciada pelo nome com possíveis curingas pelo programa X11, então o nome escolhido tem que fazer algum sentido. Pode-se começar simplesmente usando +Todos esses nomes são arbitrários, mas deve-se procurar ser compatível com as convenções existentes. Uma fonte é referenciada pelo nome, com possíveis curingas (wildcards) por um programa X11, então o nome escolhido deve fazer algum sentido. Pode-se começar simplesmente usando -[source,shell] +[source, shell] .... -…-normal-r-normal-…-p-… +...-normal-r-normal-...-p-... .... -como o nome, e então usar man:xfontsel[1] para examiná-lo e ajustar o nome com base na aparência da fonte. +esse nome, e depois usar o comando man:xfontsel[1] para examiná-lo e ajustar o nome com base na aparência da fonte. Então, para completar nosso exemplo: -[source,shell] +[source, shell] .... -Torne a fonte acessível para o X11 +Torne a fonte acessível ao X11. % cd /usr/X11R6/lib/X11/fonts/Type1 -% ln -s /usr/local/shared/fonts/type1/showboat.pfb . +% ln -s /usr/local/share/fonts/type1/showboat.pfb . -Edite os arquivos fonts.dir e fonts.scale, adicionando a linha que descreve a fonte e incremente o número de fontes que são encontradas na primeira linha. +Edite o arquivo fonts.dir e fonts.scale, adicionando a linha que descreve a fonte +e incrementando o número de fontes que é encontrado na primeira linha. % ex fonts.dir :1p 25 @@ -264,10 +270,10 @@ showboat.pfb -type1-showboat-medium-r-normal-decorative-0-0-0-0-p-0-iso8859-1 . :wq -fonts.scale aparenta ser idêntico ao fonts.dir… +O arquivo fonts.scale parece ser idêntico ao fonts.dir... % cp fonts.dir fonts.scale -Informe ao X11 que arquivos foram alterados +Informe ao X11 que as coisas mudaram. % xset fp rehash Examine a nova fonte @@ -279,32 +285,32 @@ Referências: man:xfontsel[1], man:xset[1], The X Windows System in a Nutshell, [[type1-fonts-ghostscript]] == Usando Fontes Type 1 com Ghostscript -O Ghostscript referencia uma fonte via seu arquivo de [.filename]#Fontmap#. Este deve ser modificado de uma maneira similar a feita para o arquivo [.filename]#fonts.dir# do X11. O Ghostscript pode usar tanto o formato [.filename]#.pfa# quanto o [.filename]#.pfb#. Usando a fonte do exemplo anterior, segue um passo a passo de como utilizá-la com o Ghostscript: +O Ghostscript referencia uma fonte por meio de seu arquivo [.filename]#Fontmap#. Este arquivo deve ser modificado de maneira semelhante ao arquivo [.filename]#fonts.dir# do X11. O Ghostscript pode usar fontes em formato [.filename]#.pfa# ou [.filename]#.pfb#. Usando a fonte do exemplo anterior, aqui está como usá-la com o Ghostscript: -[source,shell] +[source, shell] .... -Coloque a fonte no diretório do Ghostscript -% cd /usr/local/shared/ghostscript/fonts -% ln -s /usr/local/shared/fonts/type1/showboat.pfb . +Coloque a fonte no diretório de fontes do Ghostscript. +% cd /usr/local/share/ghostscript/fonts +% ln -s /usr/local/share/fonts/type1/showboat.pfb . -Edite o mapeamento de fontes, assim o Ghostscript saberá sobre a fonte -% cd /usr/local/shared/ghostscript/4.01 +Edite o arquivo Fontmap para que o Ghostscript saiba sobre a fonte +% cd /usr/local/share/ghostscript/4.01 % ex Fontmap :$a /Showboat (showboat.pfb) ; % From CICA /fonts/atm/showboat . :wq -Use o Ghostscript para checar a fonte +Use o Ghostscript para examinar a fonte. % gs prfont.ps Aladdin Ghostscript 4.01 (1996-7-10) Copyright (C) 1996 Aladdin Enterprises, Menlo Park, CA. All rights reserved. This software comes with NO WARRANTY: see the file PUBLIC for details. -Loading Times-Roman font from /usr/local/shared/ghostscript/fonts/tir_____.pfb... +Loading Times-Roman font from /usr/local/share/ghostscript/fonts/tir_____.pfb... /1899520 581354 1300084 13826 0 done. GS>Showboat DoFont -Loading Showboat font from /usr/local/shared/ghostscript/fonts/showboat.pfb... +Loading Showboat font from /usr/local/share/ghostscript/fonts/showboat.pfb... 1939688 565415 1300084 16901 0 done. >>showpage, press to continue<< >>showpage, press to continue<< @@ -312,16 +318,16 @@ Loading Showboat font from /usr/local/shared/ghostscript/fonts/showboat.pfb... GS>quit .... -Referências: Veja o arquivo [.filename]#fonts.txt# na distribuição do Ghostscript 4.01 +Referências: arquivo [.filename]#fonts.txt# na distribuição do Ghostscript 4.01 [[type1-fonts-groff]] -== Usando Fontes Type 1 com Groff +== Usando Fontes Type 1 com o Groff -Agora que a nova fonte pode ser utilizada tanto pelo X11 quanto pelo Ghostscript, como podemos utilizar a nova fonte com o Groff? Primeiro de tudo, como estamos usando fontes Type 1 PostScript(R), o dispositivo Groff que é aplicável é o device __ps__. Um arquivo de fonte deve ser criado para cada fonte que o Groff possa usar. Um nome de fonte Groff é apenas um arquivo no [.filename]#/usr/shared/groff_font/devps#. Com o nosso exemplo, o arquivo da fonte poderia ser [.filename]#/usr/shared/groff_font/devps/SHOWBOAT#. O arquivo deve ser criado usando ferramentas providas pelo Groff. +Agora que a nova fonte pode ser usada tanto pelo X11 quanto pelo Ghostscript, como se pode usá-la com o groff? Em primeiro lugar, uma vez que estamos lidando com fontes PostScript(R) type 1, o dispositivo groff que é aplicável é o dispositivo _ps_. Um arquivo de fonte deve ser criado para cada fonte que o groff possa usar. Um nome de fonte groff é apenas um arquivo em [.filename]#/usr/share/groff_font/devps#. Em nosso exemplo, o arquivo de fonte poderia ser [.filename]#/usr/share/groff_font/devps/SHOWBOAT#. O arquivo deve ser criado usando ferramentas fornecidas pelo groff. -A primeira ferramenta é o `afmtodit`. Ela normalmente não está instalada, então deve ser baixada de uma fonte de distribuição. Eu percebi que teria que mudar a primeira linha do arquivo, então eu fiz: +A primeira ferramenta é `afmtodit`. Ela não costuma ser instalada por padrão, então é necessário obtê-la da distribuição de origem. Descobri que precisei alterar a primeira linha do arquivo, então fiz o seguinte: -[source,shell] +[source, shell] .... % cp /usr/src/gnu/usr.bin/groff/afmtodit/afmtodit.pl /tmp % ex /tmp/afmtodit.pl @@ -331,42 +337,39 @@ A primeira ferramenta é o `afmtodit`. Ela normalmente não está instalada, ent :wq .... -Essa ferramenta irá criar o arquivo de fontes do Groff a partir dos arquivos de métrica ([.filename]#.afm# suffix.) Continuando com nosso exemplo: +Essa ferramenta criará o arquivo de fonte do groff a partir do arquivo de métricas (sufixo [.filename]#.afm#). Continuando com nosso exemplo: -[source,shell] +[source, shell] .... -Muitos arquivos .afm estão no formato do Mac, com ^M delimitando as linhas -Nós temos que convertê-los para o estilo UNIX que delimita as linhas com ^J +Muitos arquivos .afm estão no formato Mac, com linhas delimitadas por ^M. +É necessário convertê-los para o estilo UNIX(R), com linhas delimitadas por ^J. % cd /tmp -% cat /usr/local/shared/fonts/type1/showboat.afm | +% cat /usr/local/share/fonts/type1/showboat.afm | tr '\015' '\012' >showboat.afm -Agora crie um arquivo de fonte groff -% cd /usr/shared/groff_font/devps +Agora crie o arquivo de fonte do groff. +% cd /usr/share/groff_font/devps % /tmp/afmtodit.pl -d DESC -e text.enc /tmp/showboat.afm generate/textmap SHOWBOAT .... A fonte agora pode ser referenciada pelo nome SHOWBOAT. -Se o Ghostscript é utilizado para impressão com driver simulado no sistema, então não precisa fazer mais nada. Entretanto, se as impressoras usam PostScript(R) real, então a fonte deve ser baixada pela impressora de maneira que a fonte a ser utilizada (a menos que a impressora tenha a fonte showboat embutida ou acessível a partir de um disco de fontes.) O passo final é criar uma fonte descarregável. A ferramenta `pfbtops` é usada para criar o formato [.filename]#.pfa# da fonte, e o arquivo para [.filename]#download# é modificado para referenciar a nova fonte. O arquivo para [.filename]#download# deve referenciar o nome interno da fonte. Isso pode ser facilmente determinado de um arquivo de fonte groff conforme demonstrado: +Se o Ghostscript for usado para controlar as impressoras no sistema, então nada mais precisa ser feito. No entanto, se forem usadas impressoras PostScript(R) reais, a fonte deve ser baixada para a impressora para que a fonte seja usada (a menos que a impressora tenha a fonte showboat incorporada ou em um disco de fonte acessível). O último passo é criar uma fonte transferível. A ferramenta `pfbtops` é usada para criar o formato [.filename]#.pfa# da fonte, e o arquivo [.filename]#download# é modificado para referenciar a nova fonte. O arquivo [.filename]#download# deve fazer referência ao nome interno da fonte. Isso pode ser facilmente determinado a partir do arquivo de fonte do groff, como ilustrado: -[source,shell] +[source, shell] .... -Criando o arquivo de fonte .pfa - -% pfbtops /usr/local/shared/fonts/type1/showboat.pfb >showboat.pfa +Crie o arquivo de fonte .pfa. +% pfbtops /usr/local/share/fonts/type1/showboat.pfb >showboat.pfa .... -Claro que, se o arquivo [.filename]#.pfa# já existe, apenas crie um link simbólico para referenciá-lo. +Claro, se o arquivo [.filename]#.pfa# já estiver disponível, basta usar um link simbólico para fazer referência a ele. -[source,shell] +[source, shell] .... -Obtendo o nome interno da fonte - +Obtenha o nome interno da fonte % fgrep internalname SHOWBOAT internalname Showboat -Dizendo ao groff que tem que fazer o download da fonte - +Informe ao groff que a fonte deve ser baixada. % ex download :$a Showboat showboat.pfa @@ -376,14 +379,13 @@ Showboat showboat.pfa Para testar a fonte: -[source,shell] +[source, shell] .... % cd /tmp - -% cat >example.t <exemplo.t <example.ps +% groff -Tps example.t > exemplo.ps -Para usar ghostscript/ghostview +Para usar o ghostscript/ghostview % ghostview example.ps -Para imprimí-la +Para imprimir: % lpr -Ppostscript example.ps .... Referências: [.filename]#/usr/src/gnu/usr.bin/groff/afmtodit/afmtodit.man#, man:groff_font[5], man:groff_char[7], man:pfbtops[1]. [[convert-truetype]] -== Convertendo Fontes TrueType para um Formato groff/PostScript Para o Groff +== Convertendo Fontes TrueType para um Formato groff/PostScript para o Groff -Isso potencialmente requer um pouco de trabalho, simplesmente porque depende de alguns utilitários que não são instalados como parte do sistema base. Eles são: +Isso pode requerer um pouco de trabalho, simplesmente porque depende de algumas ferramentas que não são instaladas como parte do sistema base. Elas são: `ttf2pf`:: -Utilitário de conversão TrueType para PostScript. Ee permite a conversão de uma fonte TrueType em um arquivo de métrica de fonte ascii ([.filename]#.afm#). +Utilitários de conversão de TrueType para PostScript. Isso permite a conversão de uma fonte TrueType para um arquivo de métricas de fonte ascii ([.filename]#.afm#). + -Atualmente disponível em http://sunsite.icm.edu.pl/pub/GUST/contrib/BachoTeX98/ttf2pf/[http://sunsite.icm.edu.pl/pub/GUST/contrib/BachoTeX98/ttf2pf/]. Nota: Esses arquivos são programas PostScript e devem ser baixados para o disco mantendo pressionada a tecla kbd:[ Shift ] ao clicar no link. Caso contrário, seu navegador pode tentar iniciar o ghostview para visualizá-los. +Disponível atualmente em http://sunsite.icm.edu.pl/pub/GUST/contrib/BachoTeX98/ttf2pf/[http://sunsite.icm.edu.pl/pub/GUST/contrib/BachoTeX98/ttf2pf/]. Observe: esses arquivos são programas PostScript e devem ser baixados para o disco mantendo pressionada a tecla kbd:[Shift] ao clicar no link. Caso contrário, o seu navegador pode tentar abrir o ghostview para visualizá-los. + Os arquivos de interesse são: @@ -433,41 +434,41 @@ Os arquivos de interesse são: ** [.filename]#PF2AFM.PS# ** [.filename]#ttf2pf.ps# + -O caso engraçado sobre maiúsculas/minúsculas é devido ao fato de serem destinados também para os terminais DOS. O [.filename]#ttf2pf.ps# faz uso dos outros como maiúsculos, portanto, qualquer renomeação deve ser consistente com isso. (Na verdade, [.filename]#GS_TTF.PS# e [.filename]#PFS2AFM.PS# são supostamente parte da distribuição Ghostscript, mas é muito fácil usá-los como utilitários isolados. O FreeBSD parece não incluir o último.) Você também pode querer instalá-los em [.filename]#/usr/local/shared/groff_font/devps# (?). +A utilização de letras maiúsculas e minúsculas engraçadas deve-se ao fato de serem destinadas também para shells do DOS. O arquivo [.filename]#ttf2pf.ps# faz uso dos outros em letras maiúsculas, então qualquer renomeação deve ser consistente com isso. (Na verdade, os arquivos [.filename]#GS_TTF.PS# e [.filename]#PFS2AFM.PS# supostamente fazem parte da distribuição do Ghostscript, mas é fácil usá-los como uma fonte isolada. O FreeBSD não parece incluir o último.) Você também pode querer tê-los instalados em [.filename]#/usr/local/share/groff_font/devps#(?). `afmtodit`:: -Cria arquivos de fontes para uso com o Groff a partir do arquivo de métricas de fonte ascii. Isso geralmente fica no diretório [.filename]#/usr/src/contrib/groff/afmtodit# e requer algum trabalho para prosseguir. +A ferramenta `afmtodit` é utilizada para criar arquivos de fonte para o groff a partir de um arquivo métrico de fonte em formato ASCII ([.filename]#.afm#). Normalmente, essa ferramenta está localizada no diretório [.filename]#/usr/src/contrib/groff/afmtodit#, mas normalmente exige alguma configuração para funcionar corretamente. + [NOTE] ==== -Se você é paranóico sobre o trabalhar no diretório [.filename]#/usr/src#, simplesmente copie o conteúdo do diretório acima para um local de trabalho. +Se você está preocupado com a segurança de trabalhar no diretório [.filename]#/usr/src#, basta copiar o conteúdo do diretório acima para uma localização de trabalho. ==== + Na área de trabalho, você precisará compilar o utilitário. Apenas digite: + -[source,shell] +[source, shell] .... # make -f Makefile.sub afmtodit .... + -Você também pode precisar copiar o [.filename]#/usr/contrib/groff/devps/generate/textmap# para [.filename]#/usr/shared/groff_font/devps/generate# se ele ainda não existir. +Você também pode precisar copiar o arquivo [.filename]#/usr/contrib/groff/devps/generate/textmap# para [.filename]#/usr/share/groff_font/devps/generate# se ele ainda não existir. Depois que todos esses utilitários estiverem no lugar, você está pronto para começar: . Crie o arquivo [.filename]#.afm# digitando: + -[source,shell] +[source, shell] .... % gs -dNODISPLAY -q -- ttf2pf.ps TTF_name PS_font_name AFM_name .... -+ -Onde, _TTF_name_ é o seu arquivo de fonte TrueType, _PS_font_name_ é o nome do arquivo [.filename]#.pfa#, _AFM_name_ é o nome que você deseja para o arquivo [.filename]#.afm#. Se você não especificar nomes de arquivos de saída para os arquivos [.filename]#.pfa# ou [.filename]#.afm#, os nomes padrão serão gerados a partir do nome do arquivo de fonte TrueType. -+ -Isso também produz um arquivo [.filename]#.pfa#, o arquivo ascii de métricas de fonte PostScript ([.filename]#.pfb# é para o formato binário). Isso não será necessário, mas poderia (eu acho) ser útil para um fontserver. -+ ++ +Onde _TTF_nome_ é o nome do arquivo da sua fonte TrueType, _nome_fonte_PS_ é o nome do arquivo para [.filename]#.pfa#, _nome_AFM_ é o nome desejado para [.filename]#.afm#. Se você não especificar os nomes de arquivo de saída para os arquivos [.filename]#.pfa# ou [.filename]#.afm#, então nomes padrão serão gerados a partir do nome do arquivo da fonte TrueType. ++ +Isso também produz um arquivo [.filename]#.pfa#, o arquivo de métricas de fonte PostScript em formato ASCII ([.filename]#.pfb# é para a forma binária). Isso não será necessário, mas poderia (eu acredito) ser útil para um servidor de fontes. ++ Por exemplo, para converter a fonte de código de barras 30f9 usando o nome de arquivo padrão, use o seguinte comando: + -[source,shell] +[source, shell] .... % gs -dNODISPLAY -- ttf2pf.ps 3of9.ttf Aladdin Ghostscript 5.10 (1997-11-23) @@ -475,10 +476,10 @@ Copyright (C) 1997 Aladdin Enterprises, Menlo Park, CA. All rights reserved. This software comes with NO WARRANTY: see the file PUBLIC for details. Converting 3of9.ttf to 3of9.pfa and 3of9.afm. .... -+ -Se você quiser que as fontes convertidas sejam armazenadas em [.filename]#A.pfa# e [.filename]#B.afm#, use este comando: + -[source,shell] +Se você quer que as fontes convertidas sejam armazenadas em [.filename]#A.pfa# e [.filename]#B.afm#, use o seguinte comando: ++ +[source, shell] .... % gs -dNODISPLAY -- ttf2pf.ps 3of9.ttf A B Aladdin Ghostscript 5.10 (1997-11-23) @@ -487,50 +488,50 @@ This software comes with NO WARRANTY: see the file PUBLIC for details. Converting 3of9.ttf to A.pfa and B.afm. .... -. Crie o arquivo PostScript Groff: -+ -Vá para o diretório [.filename]#/usr/shared/groff_font/devps# para facilitar a execução do comando abaixo. Você provavelmente precisará de privilégios de root para isso. (Ou, se você é paranoico sobre trabalhar lá, certifique-se de referenciar os arquivos [.filename]#DESC#, [.filename]#text.enc# e [.filename]#generate/textmap# como estando neste diretório.) +. Crie o arquivo groff PostScript: ++ +Acesse o diretório `/usr/share/groff_font/devps` para facilitar a execução do seguinte comando. É provável que você precise de privilégios de root para executá-lo. (Ou, se você é paranoico em relação a trabalhar lá, certifique-se de que os arquivos `DESC`, `text.enc` e `generate/textmap` estejam localizados neste diretório.) + -[source,shell] +[source, shell] .... % afmtodit -d DESC -e text.enc file.afm generate/textmap PS_font_name .... -+ -Onde, [.filename]#file.afm# é o _AFM_name_ criado pelo `ttf2pf.ps` acima e _PS_font_name_ é o nome da fonte usada a partir desse comando, bem como o nome que man:groff[1] usará para referências a essa fonte. Por exemplo, supondo que você usou o primeiro comando `tiff2pf.ps` acima, a fonte 3of9 Barcode pode ser criada usando o comando: + -[source,shell] +Onde, [.filename]#file.afm# é o _AFM_name_ criado pelo `ttf2pf.ps` acima, e _PS_font_name_ é o nome da fonte usado no comando anterior, bem como o nome que man:groff[1] usará para referenciar essa fonte. Por exemplo, assumindo que você usou o primeiro `tiff2pf.ps` acima, a fonte Barcode 3of9 pode ser criada usando o comando: ++ +[source, shell] .... % afmtodit -d DESC -e text.enc 3of9.afm generate/textmap 3of9 .... -+ -Assegure-se de que o arquivo _PS_font_name_ resultante (por exemplo, [.filename]#3of9# no exemplo acima) esteja localizado no diretório [.filename]#/usr/shared/groff_font/devps# copiando-o ou movendo-o para lá. -+ -Note que se o [.filename]#ttf2pf.ps# atribuir um nome de fonte usando o nome que ele encontrou no arquivo de fonte TrueType e você quiser usar um nome diferente, você deverá editar o arquivo [.filename]#.afm# antes de executar o `afmtodit`. Esse nome também deve coincidir com o usado no arquivo Fontmap se você deseja redirecionar o man:groff[1] para o man:gs[1]. ++ +Certifique-se de que o arquivo _PS_font_name_ resultante (por exemplo, [.filename]#3of9# no exemplo acima) esteja localizado no diretório [.filename]#/usr/share/groff_font/devps# movendo ou copiando-o para lá. ++ +Observe que, se o [.filename]#ttf2pf.ps# atribuir um nome de fonte usando o que ele encontra no arquivo de fonte TrueType e você desejar usar um nome diferente, será necessário editar o arquivo [.filename]#.afm# antes de executar o `afmtodit`. Este nome também deve corresponder ao usado no arquivo Fontmap se você quiser redirecionar o man:groff[1] para o man:gs[1]. [[truetype-for-other-programs]] == As Fontes TrueType Podem ser Usadas com Outros Programas? -O formato de fonte TrueType é usado pelo Windows, Windows 95 e Mac. É bastante popular e há um grande número de fontes disponíveis neste formato. +O formato de fonte TrueType é utilizado pelo Windows, Windows 95 e Mac's. É bastante popular e há uma grande quantidade de fontes disponíveis neste formato. -Infelizmente, há poucos aplicativos que conheço que podem usar este formato: O Ghostscript e o Povray são os que vem a mente. O suporte do Ghostscript, de acordo com a documentação, é rudimentar e os resultados provavelmente serão inferiores as fontes Type 1. O Povray versão 3 também tem a capacidade de usar fontes TrueType, mas eu duvido que muitas pessoas criem documentos como uma série de páginas tridmensionais traçadas com luz :-). +Infelizmente, há poucos aplicativos que eu conheço que podem usar este formato: o Ghostscript e o Povray vêm à mente. O suporte do Ghostscript, de acordo com a documentação, é rudimentar e os resultados provavelmente serão inferiores aos das fontes type 1. A versão 3 do Povray também tem a capacidade de usar fontes TrueType, mas eu duvido que muitas pessoas estejam criando documentos como uma série de páginas renderizadas em raytracing :-). -Esta situação bastante triste pode mudar em breve. O http://www.freetype.org/[Projeto FreeType] está atualmente desenvolvendo um conjunto útil de ferramentas FreeType: +Essa situação um tanto quanto desanimadora pode mudar em breve. O http://www.freetype.org/[Projeto FreeType] está atualmente desenvolvendo um conjunto de ferramentas FreeType úteis: -* O servidor de fontes `xfsft` para X11 pode fornecer fontes TrueType além de fontes regulares. Embora esteja atualmente em beta, dizem que está bastante utilizável. Veja http://www.dcs.ed.ac.uk/home/jec/programs/xfsft/[a página de Juliusz Chroboczek] para maiores informações. Instruções de portabilidade para o FreeBSD podem ser encontradas na http://math.missouri.edu/~stephen/software/[página do software de Stephen Montgomery]. -* O xfstt é outro servidor de fontes para o X11, disponível em link:ftp://sunsite.unc.edu/pub/Linux/X11/fonts/[ftp://sunsite.unc.edu/pub/Linux/X11/fonts/]. -* Um programa chamado `ttf2bdf` pode produzir arquivos BDF adequados para uso em um ambiente X a partir de arquivos TrueType. Os binários para o Linux estão disponíveis em link:ftp://crl.nmsu.edu/CLR/multiling/General/[ftp://crl.nmsu.edu/CLR/multiling/Geral/]. -* e outros ... +* O servidor de fontes `xfsft` para X11 pode servir fontes TrueType além de fontes regulares. Embora esteja atualmente em beta, é dito que ele é bastante utilizável. Veja a página de http://www.dcs.ed.ac.uk/home/jec/programs/xfsft/[Juliusz Chroboczek] para obter mais informações. As instruções de portabilidade para FreeBSD podem ser encontradas em http://math.missouri.edu/~stephen/software/[página de software de Stephen Montgomery]. +* xfstt é outro servidor de fontes para X11, disponível em link:ftp://sunsite.unc.edu/pub/Linux/X11/fonts/[ftp://sunsite.unc.edu/pub/Linux/X11/fonts/]. +* Um programa chamado `ttf2bdf` pode produzir arquivos BDF adequados para uso em um ambiente X a partir de arquivos TrueType. Binários para Linux estão disponíveis em link:ftp://crl.nmsu.edu/CLR/multiling/General/[ftp://crl.nmsu.edu/CLR/multiling/General/]. +* e outros... [[obtaining-additional-fonts]] -== Onde Fontes Adicionais Podem ser Obtidas? +== Onde é possível obter fontes adicionais? -Muitas fontes estão disponíveis na Internet. Elas são totalmente gratuitas ou sharewares. Além disso, muitas fontes estão disponíveis na categoria [.filename]#x11-fonts/# na coleção do ports +Muitas fontes estão disponíveis na Internet. Elas são completamente gratuitas ou são sharewares. Além disso, muitas fontes estão disponíveis na categoria [.filename]#x11-fonts/# na coleção de ports [[additional-questions]] == Questões Adicionais -* Quais são os usos dos arquivos [.filename]#.pfm#? -* Posso gerar o arquivo [.filename]#.afm# a partir de um arquivo [.filename]#.pfa# ou [.filename]#.pfb#? -* Como gerar os arquivos de mapeamento de caracteres groff para fontes PostScript com nomes de caracteres não padrão? -* Podem os dispositivos xditview e devX serem configurados para acessar todas as novas fontes? -* Seria bom ter exemplos de uso de fontes TrueType com Povray e Ghostscript. +* Para que servem os arquivos [.filename]#.pfm#? +* É possível gerar o arquivo [.filename]#.afm# a partir de um arquivo [.filename]#.pfa# ou [.filename]#.pfb#? +* Como gerar os arquivos de mapeamento de caracteres do groff para fontes PostScript com nomes de caracteres não-padrão? +* É possível configurar o xditview e os dispositivos devX para acessar todas as novas fontes? +* Seria bom ter exemplos de como usar fontes TrueType com o Povray e o Ghostscript. diff --git a/documentation/content/pt-br/articles/fonts/_index.po b/documentation/content/pt-br/articles/fonts/_index.po new file mode 100644 index 0000000000..e64d95cdce --- /dev/null +++ b/documentation/content/pt-br/articles/fonts/_index.po @@ -0,0 +1,1615 @@ +# SOME DESCRIPTIVE TITLE +# Copyright (C) YEAR The FreeBSD Project +# This file is distributed under the same license as the FreeBSD Documentation package. +# Danilo G. Baio , 2021. +# Edson Brandi , 2023. +# "Danilo G. Baio" , 2023. +msgid "" +msgstr "" +"Project-Id-Version: FreeBSD Documentation VERSION\n" +"POT-Creation-Date: 2022-02-01 09:21-0300\n" +"PO-Revision-Date: 2023-05-02 20:44+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" +"Plural-Forms: nplurals=2; plural=n > 1;\n" +"X-Generator: Weblate 4.17\n" + +#. type: YAML Front Matter: description +#: documentation/content/en/articles/fonts/_index.adoc:1 +#, no-wrap +msgid "A description of the various font technologies in FreeBSD, and how to use them with different programs" +msgstr "" +"Uma descrição das diversas tecnologias de fontes no FreeBSD e como usá-las " +"com diferentes programas" + +#. type: Title = +#: documentation/content/en/articles/fonts/_index.adoc:1 +#: documentation/content/en/articles/fonts/_index.adoc:12 +#, no-wrap +msgid "Fonts and FreeBSD" +msgstr "Fontes e FreeBSD" + +#. type: Plain text +#: documentation/content/en/articles/fonts/_index.adoc:45 +msgid "Abstract" +msgstr "Resumo" + +#. type: Plain text +#: documentation/content/en/articles/fonts/_index.adoc:48 +msgid "" +"This document contains a description of the various font files that may be " +"used with FreeBSD and the syscons driver, X11, Ghostscript and Groff. " +"Cookbook examples are provided for switching the syscons display to 80x60 " +"mode, and for using type 1 fonts with the above application programs." +msgstr "" +"Este documento contém uma descrição dos vários arquivos de fontes que podem " +"ser usados com o FreeBSD e o driver syscons, X11, Ghostscript e Groff. " +"Exemplos de receitas são fornecidos para alternar o display syscons para o " +"modo 80x60 e para usar fontes type 1 com os programas de aplicativos " +"mencionados acima." + +#. type: Plain text +#: documentation/content/en/articles/fonts/_index.adoc:50 +msgid "'''" +msgstr "'''" + +#. type: Title == +#: documentation/content/en/articles/fonts/_index.adoc:54 +#, no-wrap +msgid "Introduction" +msgstr "Introdução" + +#. type: Plain text +#: documentation/content/en/articles/fonts/_index.adoc:59 +msgid "" +"There are many sources of fonts available, and one might ask how they might " +"be used with FreeBSD. The answer can be found by carefully searching the " +"documentation for the component that one would like to use. This is very " +"time consuming, so this tutorial is an attempt to provide a shortcut for " +"others who might be interested." +msgstr "" +"Existem muitas fontes disponíveis e alguém pode perguntar como usá-las com o " +"FreeBSD. A resposta pode ser encontrada pesquisando cuidadosamente a " +"documentação do componente que deseja utilizar. Isso pode ser muito " +"demorado, portanto, este tutorial é uma tentativa de fornecer um atalho para " +"outras pessoas interessadas." + +#. type: Title == +#: documentation/content/en/articles/fonts/_index.adoc:61 +#, no-wrap +msgid "Basic Terminology" +msgstr "Terminologia Básica" + +#. type: Plain text +#: documentation/content/en/articles/fonts/_index.adoc:65 +msgid "" +"There are many different font formats and associated font file suffixes. A " +"few that will be addressed here are:" +msgstr "" +"Existem muitos formatos diferentes de fontes e sufixos de arquivos de fontes " +"associados. Alguns que serão abordados aqui são:" + +#. type: Plain text +#: documentation/content/en/articles/fonts/_index.adoc:66 +#: documentation/content/en/articles/fonts/_index.adoc:110 +#, no-wrap +msgid "[.filename]#.pfa#, [.filename]#.pfb#" +msgstr "[.filename]#.pfa#, [.filename]#.pfb#" + +#. type: Plain text +#: documentation/content/en/articles/fonts/_index.adoc:68 +msgid "" +"PostScript(R) type 1 fonts. The [.filename]#.pfa# is the __A__scii form and " +"[.filename]#.pfb# the __B__inary form." +msgstr "" +"Fontes PostScript(R) type 1. O arquivo [.filename]#.pfa# é a forma __A__scii " +"e o arquivo [.filename]#.pfb# é a forma __B__inária." + +#. type: Labeled list +#: documentation/content/en/articles/fonts/_index.adoc:69 +#, no-wrap +msgid "[.filename]#.afm#" +msgstr "[.filename]#.afm#" + +#. type: Plain text +#: documentation/content/en/articles/fonts/_index.adoc:71 +msgid "The font metrics associated with a type 1 font." +msgstr "As métricas da fonte associado com a fonte type 1." + +#. type: Labeled list +#: documentation/content/en/articles/fonts/_index.adoc:72 +#, no-wrap +msgid "[.filename]#.pfm#" +msgstr "[.filename]#.pfm#" + +#. type: Plain text +#: documentation/content/en/articles/fonts/_index.adoc:74 +msgid "The printer font metrics associated with a type 1 font." +msgstr "As métricas da fonte para impressora associadas com a fonte type 1." + +#. type: Plain text +#: documentation/content/en/articles/fonts/_index.adoc:75 +#: documentation/content/en/articles/fonts/_index.adoc:116 +#, no-wrap +msgid "[.filename]#.ttf#" +msgstr "[.filename]#.ttf#" + +#. type: Plain text +#: documentation/content/en/articles/fonts/_index.adoc:77 +msgid "A TrueType(R) font" +msgstr "Uma fonte TrueType(R)" + +#. type: Labeled list +#: documentation/content/en/articles/fonts/_index.adoc:78 +#, no-wrap +msgid "[.filename]#.fot#" +msgstr "[.filename]#.fot#" + +#. type: Plain text +#: documentation/content/en/articles/fonts/_index.adoc:80 +msgid "An indirect reference to a TrueType font (not an actual font)" +msgstr "" +"Uma referência indireta para uma fonte TrueType (não é realmente uma fonte)" + +#. type: Labeled list +#: documentation/content/en/articles/fonts/_index.adoc:81 +#, no-wrap +msgid "[.filename]#.fon#, [.filename]#.fnt#" +msgstr "[.filename]#.fon#, [.filename]#.fnt#" + +#. type: Plain text +#: documentation/content/en/articles/fonts/_index.adoc:83 +msgid "Bitmapped screen fonts" +msgstr "Fontes de tela bitmapped" + +#. type: Plain text +#: documentation/content/en/articles/fonts/_index.adoc:86 +msgid "" +"The [.filename]#.fot# is used by Windows(R) as sort of a symbolic link to " +"the actual TrueType(R) font ([.filename]#.ttf#) file. The [.filename]#.fon# " +"font files are also used by Windows. I know of no way to use this font " +"format with FreeBSD." +msgstr "" +"O arquivo [.filename]#.fot# é usado pelo Windows(R) como um tipo de link " +"simbólico para o arquivo de fonte TrueType(R) real ([.filename]#.ttf#). Os " +"arquivos de fonte [.filename]#.fon# também são usados pelo Windows. Não " +"conheço uma maneira de usar esse formato de fonte no FreeBSD." + +#. type: Title == +#: documentation/content/en/articles/fonts/_index.adoc:88 +#, no-wrap +msgid "What Font Formats Can I Use?" +msgstr "Quais Formatos de Fonte eu Posso Utilizar?" + +#. type: Plain text +#: documentation/content/en/articles/fonts/_index.adoc:94 +msgid "" +"Which font file format is useful depends on the application being used. " +"FreeBSD by itself uses no fonts. Application programs and/or drivers may " +"make use of the font files. Here is a small cross reference of application/" +"driver to the font type suffixes:" +msgstr "" +"O formato de arquivo de fonte mais adequado depende do aplicativo utilizado. " +"O FreeBSD por si só não utiliza fontes. Programas de aplicativos e/ou " +"drivers podem fazer uso dos arquivos de fonte. Aqui está uma pequena " +"referência cruzada de aplicativos/drivers para os sufixos de tipo de fonte:" + +#. type: Labeled list +#: documentation/content/en/articles/fonts/_index.adoc:95 +#, no-wrap +msgid "Driver" +msgstr "Driver" + +#. type: Labeled list +#: documentation/content/en/articles/fonts/_index.adoc:97 +#, no-wrap +msgid "vt" +msgstr "vt" + +#. type: Plain text +#: documentation/content/en/articles/fonts/_index.adoc:99 +msgid "[.filename]#.hex#" +msgstr "[.filename]#.hex#" + +#. type: Labeled list +#: documentation/content/en/articles/fonts/_index.adoc:100 +#, no-wrap +msgid "syscons" +msgstr "syscons" + +#. type: Plain text +#: documentation/content/en/articles/fonts/_index.adoc:102 +msgid "[.filename]#.fnt#" +msgstr "[.filename]#.fnt#" + +#. type: Labeled list +#: documentation/content/en/articles/fonts/_index.adoc:103 +#, no-wrap +msgid "Application" +msgstr "Aplicação" + +#. type: Labeled list +#: documentation/content/en/articles/fonts/_index.adoc:105 +#, no-wrap +msgid "Ghostscript" +msgstr "Ghostscript" + +#. type: Plain text +#: documentation/content/en/articles/fonts/_index.adoc:107 +msgid "[.filename]#.pfa#, [.filename]#.pfb#, [.filename]#.ttf#" +msgstr "[.filename]#.pfa#, [.filename]#.pfb#, [.filename]#.ttf#" + +#. type: Labeled list +#: documentation/content/en/articles/fonts/_index.adoc:108 +#, no-wrap +msgid "X11" +msgstr "X11" + +#. type: Labeled list +#: documentation/content/en/articles/fonts/_index.adoc:111 +#, no-wrap +msgid "Groff" +msgstr "Groff" + +#. type: Plain text +#: documentation/content/en/articles/fonts/_index.adoc:113 +msgid "[.filename]#.pfa#, [.filename]#.afm#" +msgstr "[.filename]#.pfa#, [.filename]#.afm#" + +#. type: Labeled list +#: documentation/content/en/articles/fonts/_index.adoc:114 +#, no-wrap +msgid "Povray" +msgstr "Povray" + +#. type: Plain text +#: documentation/content/en/articles/fonts/_index.adoc:121 +msgid "" +"The [.filename]#.fnt# suffix is used quite frequently. I suspect that " +"whenever someone wanted to create a specialized font file for their " +"application, more often than not they chose this suffix. Therefore, it is " +"likely that files with this suffix are not all the same format; " +"specifically, the [.filename]#.fnt# files used by syscons under FreeBSD may " +"not be the same format as a [.filename]#.fnt# one encounters in the MS-" +"DOS(R)/Windows(R) environment. I have not made any attempt at using other [." +"filename]#.fnt# files other than those provided with FreeBSD." +msgstr "" +"O sufixo [.filename]#.fnt# é bastante utilizado. Eu suspeito que sempre que " +"alguém quisesse criar um arquivo de fonte especializado para seu aplicativo, " +"na maioria das vezes escolhia esse sufixo. Portanto, é provável que os " +"arquivos com esse sufixo não sejam todos do mesmo formato; especificamente, " +"os arquivos [.filename]#.fnt# usados pelo syscons no FreeBSD podem não ser " +"do mesmo formato que um [.filename]#.fnt# encontrado no ambiente MS-" +"DOS(R)/Windows(R). Não fiz nenhuma tentativa de usar outros arquivos [." +"filename]#.fnt# além daqueles fornecidos com o FreeBSD." + +#. type: Title == +#: documentation/content/en/articles/fonts/_index.adoc:123 +#, no-wrap +msgid "Setting a Virtual Console to 80x60 Line Mode" +msgstr "Configurando um Console Virtual para o Modo de Linhas 80x60" + +#. type: Plain text +#: documentation/content/en/articles/fonts/_index.adoc:127 +msgid "" +"First, an 8x8 font must be loaded. To do this, [.filename]#/etc/rc.conf# " +"should contain the line (change the font name to an appropriate one for your " +"locale):" +msgstr "" +"Primeiramente, uma fonte 8x8 deve ser carregada. Para isso, o arquivo [." +"filename]#/etc/rc.conf# deve conter a linha (mude o nome da fonte para um " +"apropriado para sua localização):" + +#. type: delimited block . 4 +#: documentation/content/en/articles/fonts/_index.adoc:131 +#, no-wrap +msgid "font8x8=\"iso-8x8\"\t\t# font 8x8 from /usr/share/syscons/fonts/* (or NO).\n" +msgstr "" +"font8x8=\"iso-8x8\"\t\t# font 8x8 from /usr/share/syscons/fonts/* (or NO).\n" + +#. type: Plain text +#: documentation/content/en/articles/fonts/_index.adoc:134 +msgid "The command to actually switch the mode is man:vidcontrol[1]:" +msgstr "O comando para realmente mudar o modo é man:vidcontrol[1]:" + +#. type: delimited block . 4 +#: documentation/content/en/articles/fonts/_index.adoc:138 +#, no-wrap +msgid "% vidcontrol VGA_80x60\n" +msgstr "% vidcontrol VGA_80x60\n" + +#. type: Plain text +#: documentation/content/en/articles/fonts/_index.adoc:142 +msgid "" +"Various screen-oriented programs, such as man:vi[1], must be able to " +"determine the current screen dimensions. As this is achieved this through " +"`ioctl` calls to the console driver (such as man:syscons[4]) they will " +"correctly determine the new screen dimensions." +msgstr "" +"Vários programas orientados a tela, como man:vi[1], devem ser capazes de " +"determinar as dimensões atuais da tela. Como isso é alcançado por meio de " +"chamadas `ioctl` para o driver do console (como man:syscons[4]), eles " +"determinarão corretamente as novas dimensões da tela." + +#. type: Plain text +#: documentation/content/en/articles/fonts/_index.adoc:145 +msgid "" +"To make this more seamless, one can embed these commands in the startup " +"scripts so it takes place when the system boots. To do this is add this " +"line to [.filename]#/etc/rc.conf#." +msgstr "" +"Para tornar isso mais contínuo, é possível incorporar esses comandos nos " +"scripts de inicialização para que ocorram durante a inicialização do " +"sistema. Para fazer isso, adicione esta linha ao arquivo [.filename]#/etc/rc." +"conf#." + +#. type: delimited block . 4 +#: documentation/content/en/articles/fonts/_index.adoc:149 +#, no-wrap +msgid "allscreens_flags=\"VGA_80x60\"\t# Set this vidcontrol mode for all virtual screens\n" +msgstr "" +"allscreens_flags=\"VGA_80x60\"\t# Set this vidcontrol mode for all virtual " +"screens\n" + +#. type: Plain text +#: documentation/content/en/articles/fonts/_index.adoc:152 +msgid "References: man:rc.conf[5], man:vidcontrol[1]." +msgstr "Referências: man:rc.conf[5], man:vidcontrol[1]." + +#. type: Title == +#: documentation/content/en/articles/fonts/_index.adoc:154 +#, no-wrap +msgid "Using Type 1 Fonts with X11" +msgstr "Usando fontes Type 1 com o X11" + +#. type: Plain text +#: documentation/content/en/articles/fonts/_index.adoc:159 +msgid "" +"X11 can use either the [.filename]#.pfa# or the [.filename]#.pfb# format " +"fonts. The X11 fonts are located in various subdirectories under [." +"filename]#/usr/X11R6/lib/X11/fonts#. Each font file is cross referenced to " +"its X11 name by the contents of [.filename]#fonts.dir# in each directory." +msgstr "" +"O X11 pode usar fontes em formato [.filename]#.pfa# ou [.filename]#.pfb#. As " *** 1237 LINES SKIPPED *** From nobody Wed May 3 01:31:59 2023 X-Original-To: dev-commits-doc-all@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4Q9zvM5YLpz48hZ8 for ; Wed, 3 May 2023 01:31:59 +0000 (UTC) (envelope-from git@FreeBSD.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Q9zvM2M3hz45Hk; Wed, 3 May 2023 01:31:59 +0000 (UTC) (envelope-from git@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1683077519; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=6pcirIV8/TNgREJwtU1wBiiYnFHuKQhrYQCG/k6wcZs=; b=Sebp/R1VcWRTRP/neNtEeZSGavj2ANZe6478K1ALo0IPjZxANY8ShXSeECsJKdAE7smlwv MFNhKTYa3XND2wuyTRBYJGfwrqiVjncVd8Dy4edJydgJIjUq/E4M5H+fVCgbe00F0qif69 DskzUfNtC1XUOxKYl2imudAmzv1Z9FEpLAfVB1RkYaqd6bC3OSY3LT5tb1Hb77haADM5WO /K+d+HdtnoLHrGeB/NIaeRheMF9YI/3AqzVAB8OVfVJ9iS428YQ9Sm9uU6QgPOpE7YAgny r91gRkSyNVxFEqYAbDRXkF2327OuSEd+USbZJaWq9Ry6p3Z6gbhvBhMMGrojyA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1683077519; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=6pcirIV8/TNgREJwtU1wBiiYnFHuKQhrYQCG/k6wcZs=; b=XpVwwWVrOrobkxStEyDtb+GQe0PloJquKKVKSLv9GfLuvOItW4l4Bo9llD1EeGCdqzdc7x cdK+V+eUa+LRP7bqaMMbMHP7LY2J5AZwJLja/aVMyYI6nsln8hTQZVQ3uEKakzMkXVgbhS gt0bDAuzrRXx1jqSHkuDsvk9SJIFaDDEjjiZ/EUBTrne9jyR0WdEN3rRuu410sv66Kx5VV 8+NyN87gPg7yUwhHINtcxiXmf+O0nvWLo2Gu+bEb/Zksys8KbzG/SKNMvmdpOPolejo2M+ 50WDMBAWi8Q/hHX/USN9Hi8A9KRbT+dwdJEAmR9wVy3ubRfV2C21PxzKy7FmbQ== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1683077519; a=rsa-sha256; cv=none; b=t3ETLELDl0CitywLfcNYaLkkgaM5FXXYKAYo655+XVkhtzlxVXHPByDqrWuxsCgHMvUkrf RxzQejFkB53R0aD4MVik3saVzk78ZOKPPIy0AtYUqWwA/jGbjRq5O73oQ+Zp/sG73B9sxt R7zNSpiJ9RhbrTYCMl1zln7i9U+s1KQgh+aXVqtJiwHfq7ft1Oyan9Zs1cZ+CHKBnBrRNW 7aHci9Ld6WaRN90ux079b7ig6Y146S3FrHKgWZ5tgJolrRSY5H1Cuqr2RtDucU5lBGYQFS AmiH0VbbCyn3xPdOInl+ssj3QBjbBdeTjhY1TdYRfXpj+6A00bjsLn0Nk/nJZA== Received: from gitrepo.freebsd.org (gitrepo.freebsd.org [IPv6:2610:1c1:1:6068::e6a:5]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 4Q9zvM1QyTz1B1m; Wed, 3 May 2023 01:31:59 +0000 (UTC) (envelope-from git@FreeBSD.org) Received: from gitrepo.freebsd.org ([127.0.1.44]) by gitrepo.freebsd.org (8.16.1/8.16.1) with ESMTP id 3431Vx8L084113; Wed, 3 May 2023 01:31:59 GMT (envelope-from git@gitrepo.freebsd.org) Received: (from git@localhost) by gitrepo.freebsd.org (8.16.1/8.16.1/Submit) id 3431VxEZ084112; Wed, 3 May 2023 01:31:59 GMT (envelope-from git) Date: Wed, 3 May 2023 01:31:59 GMT Message-Id: <202305030131.3431VxEZ084112@gitrepo.freebsd.org> To: doc-committers@FreeBSD.org, dev-commits-doc-all@FreeBSD.org From: Graham Perrin Subject: git: f881341061 - main - FreeBSD Handbook: Virtualization: HAL List-Id: Commit messages for all branches of the doc repository List-Archive: https://lists.freebsd.org/archives/dev-commits-doc-all List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-dev-commits-doc-all@freebsd.org X-BeenThere: dev-commits-doc-all@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Git-Committer: grahamperrin X-Git-Repository: doc X-Git-Refname: refs/heads/main X-Git-Reftype: branch X-Git-Commit: f881341061558ccfd0f65309a40a312a4d929732 Auto-Submitted: auto-generated X-ThisMailContainsUnwantedMimeParts: N The branch main has been updated by grahamperrin: URL: https://cgit.FreeBSD.org/doc/commit/?id=f881341061558ccfd0f65309a40a312a4d929732 commit f881341061558ccfd0f65309a40a312a4d929732 Author: Graham Perrin AuthorDate: 2023-05-03 01:25:53 +0000 Commit: Graham Perrin CommitDate: 2023-05-03 01:25:53 +0000 FreeBSD Handbook: Virtualization: HAL https://www.freshports.org/sysutils/hal/ – the port of HAL died more than two years ago. Remove related texts from: https://docs.freebsd.org/en/books/handbook/virtualization/#virtualization-guest-virtualbox https://docs.freebsd.org/en/books/handbook/virtualization/#virtualization-virtualbox-host-dvd-cd-access --- .../en/books/handbook/virtualization/_index.adoc | 50 ---------------------- 1 file changed, 50 deletions(-) diff --git a/documentation/content/en/books/handbook/virtualization/_index.adoc b/documentation/content/en/books/handbook/virtualization/_index.adoc index 5c37d9ba18..a4540edca2 100644 --- a/documentation/content/en/books/handbook/virtualization/_index.adoc +++ b/documentation/content/en/books/handbook/virtualization/_index.adoc @@ -326,44 +326,6 @@ Section "InputDevice" EndSection .... -HAL users should create the following [.filename]#/usr/local/etc/hal/fdi/policy/90-vboxguest.fdi# or copy it from [.filename]#/usr/local/share/hal/fdi/policy/10osvendor/90-vboxguest.fdi#: - -[.programlisting] -.... - - - - - - - input - input.mouse - vboxmouse - /dev/vboxguest - - - - -.... - Shared folders for file transfers between host and VM are accessible by mounting them using `mount_vboxvfs`. A shared folder can be created on the host using the VirtualBox GUI or via `vboxmanage`. For example, to create a shared folder called _myshare_ under [.filename]#/mnt/bsdboxshare# for the VM named _BSDBox_, run: @@ -511,18 +473,6 @@ Then choose the Host Drive from the popup menu for the virtual CD/DVD drive sele A checkbox labeled `Passthrough` will appear. This allows the virtual machine to use the hardware directly. For example, audio CDs or the burner will only function if this option is selected. -HAL needs to run for VirtualBox(TM)DVD/CD functions to work, so enable it in [.filename]#/etc/rc.conf# and start it if it is not already running: - -[.programlisting] -.... -hald_enable="YES" -.... - -[source,shell] -.... -# service hald start -.... - In order for users to be able to use VirtualBox(TM)DVD/CD functions, they need access to [.filename]#/dev/xpt0#, [.filename]#/dev/cdN#, and [.filename]#/dev/passN#. This is usually achieved by making the user a member of `operator`. Permissions to these devices have to be corrected by adding these lines to [.filename]#/etc/devfs.conf#: From nobody Wed May 3 07:40:07 2023 X-Original-To: dev-commits-doc-all@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4QB8481vLFz492qj for ; Wed, 3 May 2023 07:40:08 +0000 (UTC) (envelope-from git@FreeBSD.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4QB8481NFDz4Xg9; Wed, 3 May 2023 07:40:08 +0000 (UTC) (envelope-from git@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1683099608; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=tbOZ+KKq11aGhK1UlDw2H0Y5jUkaxa+o3wSbrAZenuI=; b=QqGaWKT91xljtseY2FC9lOjWL+T4+wzIWd6mM25bIsef5RF4ul7LoUIETB+QTGi4Sedz8X nc/7DMfJQpoJSnVPonc5MeafBoIvGe2LQzjBSrGrxXRUfASNP9VTJOY/lgrSqhAYELa7UT M/hf1eBGD6pr4kzHCBSkblNv4HhmMZsiQ+Nts0usNfTjvhrFU2AzFu6lQtQFTKWqJPr6UT 0JOC3uJ+w/DHucbMMIOtnMlGYozr/07KNNJGa1tnErwKRuD0gr+KcWvy9VRiNqSkQJ7q5N DS7vXi08XKEwGzg4PFa8dywZHzEu1IxbmlL0iOS7DlL3dEQy6epO8gRhMUy4sg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1683099608; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=tbOZ+KKq11aGhK1UlDw2H0Y5jUkaxa+o3wSbrAZenuI=; b=pxjXEruACLXqBrm3mAI878rE2kqInUeKIsfiL9+uB262hkRRIHPO3YAYUW4vNf2z8fh1Ls fhZlcTtxA7uLaIdtddcrsnh6KgrcmX7fZ8VyRtTEWxxKYLIfTIh6ymRk/jLIlLaeZi321S S7B45TqpvMVIzjuhUoNDrbkoVsudPWEljDAYTmuXg7D4kT7hd8Y+3ZzMa2Ms3JdaZ/AMlM ymB7cN5QShzcM0SmNwcT4DDqae/1xqBonRQxEGPEqV2rATRTtxt7mYtVJF2Aiu0SqBQwYl wP2hHmp/M2lGrD8cfmMzXo9c1OrBCRIe6nYwLGvwlglbA5IOW6vO7HPCIHS6gw== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1683099608; a=rsa-sha256; cv=none; b=cWvSjFxA8IzEJMWp9LulXK2fMSKgA5GxdHsTDPv8slTgmQ1c1SrUs9jQ7POxQKlvzesgr9 bQ04H2HARdXoukmfnZyk40pliBPzqjyV/gEX/Q51TTFMAwYoer9NAe5C/NLkx2qhEhdRYp V8IpxZXo3kW3ZvZJ6d2rgeBL9Btb2ssoJMATo0k7VFL9Cd0rGujWr99Oq6y4e0jCCewc/Y iItQvnQqjK1olcGaAqdlbWpRNSiqAdr9R+0pQ3dRYJhzFdkGVduRY2TrOQ142XATr0KPxk OKsgNc3CMdv0TFlvT3jjAGbokFlmrMcq9G1H6N8bufHcLCICE5XTP5LTcgaTEg== Received: from gitrepo.freebsd.org (gitrepo.freebsd.org [IPv6:2610:1c1:1:6068::e6a:5]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 4QB8480Rz0zMcZ; Wed, 3 May 2023 07:40:08 +0000 (UTC) (envelope-from git@FreeBSD.org) Received: from gitrepo.freebsd.org ([127.0.1.44]) by gitrepo.freebsd.org (8.16.1/8.16.1) with ESMTP id 3437e7B6086721; Wed, 3 May 2023 07:40:07 GMT (envelope-from git@gitrepo.freebsd.org) Received: (from git@localhost) by gitrepo.freebsd.org (8.16.1/8.16.1/Submit) id 3437e7wZ086718; Wed, 3 May 2023 07:40:07 GMT (envelope-from git) Date: Wed, 3 May 2023 07:40:07 GMT Message-Id: <202305030740.3437e7wZ086718@gitrepo.freebsd.org> To: doc-committers@FreeBSD.org, dev-commits-doc-all@FreeBSD.org From: Lorenzo Salvadore Subject: git: 03dca8208a - main - fdp-primer: Add trademarks List-Id: Commit messages for all branches of the doc repository List-Archive: https://lists.freebsd.org/archives/dev-commits-doc-all List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-dev-commits-doc-all@freebsd.org X-BeenThere: dev-commits-doc-all@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Git-Committer: salvadore X-Git-Repository: doc X-Git-Refname: refs/heads/main X-Git-Reftype: branch X-Git-Commit: 03dca8208a291f760cf0846f76730e7c7452e565 Auto-Submitted: auto-generated X-ThisMailContainsUnwantedMimeParts: N The branch main has been updated by salvadore: URL: https://cgit.FreeBSD.org/doc/commit/?id=03dca8208a291f760cf0846f76730e7c7452e565 commit 03dca8208a291f760cf0846f76730e7c7452e565 Author: Lorenzo Salvadore AuthorDate: 2023-04-27 10:23:23 +0000 Commit: Lorenzo Salvadore CommitDate: 2023-05-03 07:38:15 +0000 fdp-primer: Add trademarks Add the FreeBSD and Git trademarks to the the trademarks list. Also forward commit 949582900fdaff5b8157a752fa8039a1887eba6c to book.adoc. Approved by: carlavilla (mentor) Differential Revision: https://reviews.freebsd.org/D39847 --- documentation/content/en/books/fdp-primer/_index.adoc | 2 +- documentation/content/en/books/fdp-primer/book.adoc | 4 ++-- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/documentation/content/en/books/fdp-primer/_index.adoc b/documentation/content/en/books/fdp-primer/_index.adoc index 75c3c0e507..98409c970e 100644 --- a/documentation/content/en/books/fdp-primer/_index.adoc +++ b/documentation/content/en/books/fdp-primer/_index.adoc @@ -3,7 +3,7 @@ title: FreeBSD Documentation Project Primer for New Contributors authors: - author: The FreeBSD Documentation Project copyright: 1998-2023 The FreeBSD Documentation Project -trademarks: ["general"] +trademarks: ["freebsd", "general", "git"] description: Everything you need to know in order to start contributing to the FreeBSD Documentation Project next: books/fdp-primer/preface tags: ["FDP", "documentation", "FreeBSD", "Index"] diff --git a/documentation/content/en/books/fdp-primer/book.adoc b/documentation/content/en/books/fdp-primer/book.adoc index 0a0e43a665..151fec0747 100644 --- a/documentation/content/en/books/fdp-primer/book.adoc +++ b/documentation/content/en/books/fdp-primer/book.adoc @@ -2,9 +2,9 @@ title: FreeBSD Documentation Project Primer for New Contributors authors: - author: The FreeBSD Documentation Project -copyright: 1998-2021 DocEng +copyright: 1998-2023 The FreeBSD Documentation Project description: Everything you need to know in order to start contributing to the FreeBSD Documentation Project -trademarks: ["general"] +trademarks: ["freebsd", "general", "git"] tags: ["FDP", "documentation", "FreeBSD", "Index"] add_split_page_link: true --- From nobody Wed May 3 08:07:53 2023 X-Original-To: dev-commits-doc-all@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4QB8hB1SjLz494Tk for ; Wed, 3 May 2023 08:07:54 +0000 (UTC) (envelope-from git@FreeBSD.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4QB8hB0gHKz4c9f; Wed, 3 May 2023 08:07:54 +0000 (UTC) (envelope-from git@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1683101274; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=gI9zKp+w0QES7w92FQRu32JY3oDcgdPTzMnKNuZoks8=; b=nVxC+gH7vbLD+NL/7FB80gdRYeZjd4v1HH6lU1+FR7X+1MyttlNdT58SVHqDMmtEaAv8UW 4lCnJi93gBWRoBC7Wc8PmOS+v8nCLwUQiZy5aqpE+Q/YJ94zPbHPOMaC/8v9HKv+ftussb TKYNFPTaogoXkYGkBaaEawC8OPKd0kq2AU+oe4jqe/OtKYNHeHKaiRYEXOtjQer4WAohBe JwCJk5ln0nA4zHfkkTcAeCDySmrs7jYrTLkwihwefADb43yN+a6Hx6EG0CoRNM7vWPJGQu DHF9jHmDEDvoiY5aD2sis1JL8wMg+H+1qGN3qM59V5hvAxrR6Gi8yBpl83Okdw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1683101274; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=gI9zKp+w0QES7w92FQRu32JY3oDcgdPTzMnKNuZoks8=; b=ix7oCOe1Apj+JymKjOKp84owcfjhURTe59c2yrwPIcvK32MdSh2v9Z9vyDxkLDZ9G59hhH Ga+Wmcmy3ZReL3y/hmE4HRY7WhPhHkxQOreDu3WLqiLj9G9XqQyEeloF60EsNSNPstlMk5 43cVOmTsD5rYrxji+lsnMt3X1uZFv3j86X08ucY3RiMxIhAkfj0ALgG1BOD5x9f5tkPfHh bGIMi/oO82xjVw3MTH//VRhKO5yrQ8Oe/w3Yb1oNKN751LBqjXOk4+YWWIzkGV3xJRG7aB 0EIdIo62iSSEPqt6e7QqDFeE9lGfSIOXz+IM+7LHj7YhwywwjeXkCdrzmWn/Jg== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1683101274; a=rsa-sha256; cv=none; b=GFbo52UHCebDDkRp7hnrFyYQvaxyg7gby5LBEf6gWor82qRqhdExdLipP/AlOpV1PLtF/j qa9t37D6VByFaR26J3YM7fXa9zBW8W/IuCmfbFfVHfQt2Kd7AiS2uN0pLwQq0uTVojsROr jMo8lRSwypqq7OZr+MTXWSjq8sxWCm7ciMgZFmMrX9OjqbRxdc7DIhyfNL8htE74M1q+Fe mxWjzMezO1Ljg2fo+G4ey3VApFbZPReaAactmjhIUTzJmLOdCVzunQYM7qHFd/i9ufMcq0 15K1tGnKDyBWT71s3T1SKrZEyO4KO2C/ixBlltr13VjoYlGeR6n9miU7MiSd8Q== Received: from gitrepo.freebsd.org (gitrepo.freebsd.org [IPv6:2610:1c1:1:6068::e6a:5]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 4QB8h96qbkzMt6; Wed, 3 May 2023 08:07:53 +0000 (UTC) (envelope-from git@FreeBSD.org) Received: from gitrepo.freebsd.org ([127.0.1.44]) by gitrepo.freebsd.org (8.16.1/8.16.1) with ESMTP id 34387rNX033416; Wed, 3 May 2023 08:07:53 GMT (envelope-from git@gitrepo.freebsd.org) Received: (from git@localhost) by gitrepo.freebsd.org (8.16.1/8.16.1/Submit) id 34387rgb033415; Wed, 3 May 2023 08:07:53 GMT (envelope-from git) Date: Wed, 3 May 2023 08:07:53 GMT Message-Id: <202305030807.34387rgb033415@gitrepo.freebsd.org> To: doc-committers@FreeBSD.org, dev-commits-doc-all@FreeBSD.org From: Lorenzo Salvadore Subject: git: fc54c493da - main - fdp-primer/working-copy: Improve git installation instructions List-Id: Commit messages for all branches of the doc repository List-Archive: https://lists.freebsd.org/archives/dev-commits-doc-all List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-dev-commits-doc-all@freebsd.org X-BeenThere: dev-commits-doc-all@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Git-Committer: salvadore X-Git-Repository: doc X-Git-Refname: refs/heads/main X-Git-Reftype: branch X-Git-Commit: fc54c493dacfc5ca62279113455e6ded3dd98012 Auto-Submitted: auto-generated X-ThisMailContainsUnwantedMimeParts: N The branch main has been updated by salvadore: URL: https://cgit.FreeBSD.org/doc/commit/?id=fc54c493dacfc5ca62279113455e6ded3dd98012 commit fc54c493dacfc5ca62279113455e6ded3dd98012 Author: Lorenzo Salvadore AuthorDate: 2023-05-03 07:26:33 +0000 Commit: Lorenzo Salvadore CommitDate: 2023-05-03 08:07:42 +0000 fdp-primer/working-copy: Improve git installation instructions - Describe the alternative between git and git-lite. - Use the package macro. Approved by: carlavilla (mentor) Differential Revision: https://reviews.freebsd.org/D39944 --- documentation/content/en/books/fdp-primer/working-copy/_index.adoc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/documentation/content/en/books/fdp-primer/working-copy/_index.adoc b/documentation/content/en/books/fdp-primer/working-copy/_index.adoc index a729bf590d..5b15db2186 100644 --- a/documentation/content/en/books/fdp-primer/working-copy/_index.adoc +++ b/documentation/content/en/books/fdp-primer/working-copy/_index.adoc @@ -54,7 +54,7 @@ A full copy of the documentation tree can occupy 550 megabytes of disk space. Allow for a full gigabyte of space to have room for temporary files and test versions of various output formats. link:https://git-scm.com/[Git] is used to manage the FreeBSD documentation files. -It is obtained by installing the Git package: +It is obtained by installing the package:devel/git[] package, which also has a lighter flavor called git-lite: [source,shell] .... From nobody Wed May 3 18:40:52 2023 X-Original-To: dev-commits-doc-all@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4QBQkX3pzyz497QT for ; Wed, 3 May 2023 18:40:52 +0000 (UTC) (envelope-from git@FreeBSD.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4QBQkX3gnKz3LdW; Wed, 3 May 2023 18:40:52 +0000 (UTC) (envelope-from git@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1683139252; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=0+av8P0QHqmDdeaWsfQXZUONv+22ga/QM8Nnj5M+OcM=; b=f2jKYPtoSv3ANGE5+lIgXlcqTrgecjepiJjydb7nsN8yyiUMnTFesRB8mNy2QMYhf8FOaV BTP9NG74ZRZ9b2Vzx6XlvHpABPHl0dLoiDaiZU5E9EO9gzm1KUTOHxGR/RCiNIyGSO0Cn4 kqy0Qcw/zsmDQJbtbK5hVv7rJI19p+p2AiP+TlEu9ZBPoCP3zPXwo1pTtlJO4Z4DR4tttu SbLcFLPPR3pxTuuvJZl1RJaB7noUoySYWBZ346utdMOoaqap83I4qXawAmZ4UeMhov/qup +jk0r5IPAN7dds9drqo9mCe3rRXouPQedWpG/DEPKYakxJU/YBQSP4/wZoUKEA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1683139252; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=0+av8P0QHqmDdeaWsfQXZUONv+22ga/QM8Nnj5M+OcM=; b=O6De74qSvJUxo8J2Sm09VLfM+KKRIzlKS150v9DtEKHLfg3XHeiRUDTi3tgkWmIvtxEcvm //GB9TpX7gbsOwLs55VLNEOo6MoWYXS8h6LJG+mPiFcr5yu1RrZuSUiDvtrBZS+0KmdckH p0ZNBSwNK2FUv9wG8MuhTEPocd34MlnB6W55BU3zk2VqZrO8iyqCbqwx0xTi9De7dyGqAV AixBd3LMaxHmn/UZNtbdvH2EiPL2br05+GWF/dBf/bvJOsOnF2DWN06oydHSw6H8G6nGQp JFpPrF/oJhRfGfhDhRIwhFMboY39iwVN0peLrNWe7NIv2kEtwyt4nFnjA9USSg== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1683139252; a=rsa-sha256; cv=none; b=HhSItKRv3gCIrDv3F7pm4GIwn5VCQfLg4sISzBD/NldR1XMBjxLKX7stTS9bwrrZxRTlVn WDQaSPbpQcwQMdf+PSZkLj2G2Fu9PYvCSqk/Vca9Fu8xOowIxb5G9T7Yt6NgqJRM9a0j0s /Q9rEOb90tlm5VREViHAHcSCmEUQrEwJElTdeBWbuIKdjsDzJg5p8tci56HpSlN2IsMr8z W2lppCSRO4vqpGFBWFxEUE2m4AuYw+rFt7zHY9Dj7VuSUwGH9GrpVKfjAzhpSEw/HZdsvs xY92Yj64VpaT+vJMQ3gOftMsdN6S/IOQd4iuepz9gn5W/7RlWv00uyHofSyHNg== Received: from gitrepo.freebsd.org (gitrepo.freebsd.org [IPv6:2610:1c1:1:6068::e6a:5]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 4QBQkX2l89zh6N; Wed, 3 May 2023 18:40:52 +0000 (UTC) (envelope-from git@FreeBSD.org) Received: from gitrepo.freebsd.org ([127.0.1.44]) by gitrepo.freebsd.org (8.16.1/8.16.1) with ESMTP id 343IeqAo084765; Wed, 3 May 2023 18:40:52 GMT (envelope-from git@gitrepo.freebsd.org) Received: (from git@localhost) by gitrepo.freebsd.org (8.16.1/8.16.1/Submit) id 343IeqEc084764; Wed, 3 May 2023 18:40:52 GMT (envelope-from git) Date: Wed, 3 May 2023 18:40:52 GMT Message-Id: <202305031840.343IeqEc084764@gitrepo.freebsd.org> To: doc-committers@FreeBSD.org, dev-commits-doc-all@FreeBSD.org From: Sergio Carlavilla Delgado Subject: git: fa6d03936e - main - Handbook - linuxemu: Chapter upgrade List-Id: Commit messages for all branches of the doc repository List-Archive: https://lists.freebsd.org/archives/dev-commits-doc-all List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-dev-commits-doc-all@freebsd.org X-BeenThere: dev-commits-doc-all@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Git-Committer: carlavilla X-Git-Repository: doc X-Git-Refname: refs/heads/main X-Git-Reftype: branch X-Git-Commit: fa6d03936edfbd635af35279131da3ca6d985e94 Auto-Submitted: auto-generated X-ThisMailContainsUnwantedMimeParts: N The branch main has been updated by carlavilla: URL: https://cgit.FreeBSD.org/doc/commit/?id=fa6d03936edfbd635af35279131da3ca6d985e94 commit fa6d03936edfbd635af35279131da3ca6d985e94 Author: Sergio Carlavilla Delgado AuthorDate: 2023-05-03 18:36:00 +0000 Commit: Sergio Carlavilla Delgado CommitDate: 2023-05-03 18:36:00 +0000 Handbook - linuxemu: Chapter upgrade * Improvements in the chapter * Upgrade Debian / Ubuntu Base System with debootstrap Reviewed by: arrowd@, fernape@, karels@ Differential Revision: https://reviews.freebsd.org/D39666 --- .../content/en/books/handbook/linuxemu/_index.adoc | 298 ++++++++++++++------- 1 file changed, 206 insertions(+), 92 deletions(-) diff --git a/documentation/content/en/books/handbook/linuxemu/_index.adoc b/documentation/content/en/books/handbook/linuxemu/_index.adoc index e9d720ef51..79892d7cfa 100644 --- a/documentation/content/en/books/handbook/linuxemu/_index.adoc +++ b/documentation/content/en/books/handbook/linuxemu/_index.adoc @@ -51,11 +51,14 @@ endif::[] [[linuxemu-synopsis]] == Synopsis -FreeBSD provides optional binary compatibility with Linux(R), allowing users to install and run unmodified Linux binaries. -It is available for the i386, amd64, and arm64 architectures. - +FreeBSD provides *optional* binary compatibility with Linux(R), commonly referred to as Linuxulator, allowing users to install and run unmodified Linux binaries. +It is available for the x86 (both 32 and 64 bit) and AArch64 architectures. Some Linux-specific operating system features are not yet supported; this mostly happens with functionality specific to hardware or related to system management, such as cgroups or namespaces. +Before reading this chapter, you should: + +* Know how to install crossref:ports[ports,additional third-party software]. + After reading this chapter, you will know: * How to enable Linux binary compatibility on a FreeBSD system. @@ -63,100 +66,243 @@ After reading this chapter, you will know: * How to install Linux applications on a FreeBSD system. * The implementation details of Linux compatibility in FreeBSD. -Before reading this chapter, you should: - -* Know how to install crossref:ports[ports,additional third-party software]. - [[linuxemu-lbc-install]] == Configuring Linux Binary Compatibility -By default, Linux binary compatibility is not enabled. -To enable it at boot time, add this line to [.filename]#/etc/rc.conf#: +By default, man:linux[4] binary compatibility is not enabled. + +To enable the Linux ABI at boot time, execute the following command: [.programlisting] .... -linux_enable="YES" +# sysrc linux_enable="YES" .... -Once enabled, it can be started without rebooting by running: +Once enabled, it can be started without rebooting executing the following command: + [source,shell] .... # service linux start .... -The [.filename]#/etc/rc.d/linux# script will load necessary kernel modules and mount filesystems expected by Linux applications under [.filename]#/compat/linux#. This is enough for statically linked Linux binaries to work. + +The Linux service will load necessary kernel modules and mount filesystems expected by Linux applications under [.filename]#/compat/linux#. They can be started in the same way native FreeBSD binaries can; they behave almost exactly like native processes and can be traced and debugged the usual way. -Linux binaries linked dynamically (which is the vast majority) also require Linux shared libraries to be installed - they can run on top of the FreeBSD kernel, but they cannot use FreeBSD libraries; this is similar to how 32-bit binaries cannot use native 64-bit libraries. -There are several ways of providing those libraries: one can copy them over from an existing Linux installation using the same architecture, install them from FreeBSD packages, or install using man:debootstrap[8] (from package:sysutils/debootstrap[]), and others. +The current content of [.filename]#/compat/linux# can be checked executing the following command: -[[linuxemu-packages]] -== CentOS Base System from FreeBSD Packages +[source,shell] +.... +# ls -l /compat/linux/ +.... -[NOTE] +The output should be similar to the following: + +[.programlisting] +.... +total 1 +dr-xr-xr-x 13 root wheel 512 Apr 11 19:12 dev +dr-xr-xr-x 1 root wheel 0 Apr 11 21:03 proc +dr-xr-xr-x 1 root wheel 0 Apr 11 21:03 sys +.... + +[[linux-userlands]] +== Linux userlands + +Linux software requires more than just an ABI to work. +In order to run Linux software a Linux userland must be installed first. + +[TIP] ==== -This method is not yet available for arm64. +If all that is wanted is to run some software already included in the Ports tree, it can be installed via package manager and man:pkg[8] will automatically setup the required Linux userland. + +For example, to install Sublime Text 4, along with all the Linux libraries it depends on, run this command: + +[source,shell] +.... +# pkg install linux-sublime-text4 +.... ==== -The easiest way to install Linux libraries is to install package:emulators/linux_base-c7[] package or port, which places the CentOS 7-derived base system into [.filename]#/compat/linux#: +[[linuxemu-packages]] +=== CentOS Base System from FreeBSD Packages + +To install the CentOS userland execute the following command: [source,shell] .... # pkg install linux_base-c7 .... -FreeBSD provides packages for some Linux binary applications. -For example, to install Sublime Text 4, along with all the Linux libraries it depends on, run this command: +package:emulators/linux_base-c7[] will place the base system derived from CentOS 7 into [.filename]#/compat/linux#. + +After installing the package, the contents of [.filename]#/compat/linux# can be verified by running the following command to check that the CentOS userland has been installed: + [source,shell] .... -# pkg install linux-sublime-text4 +# ls -l /compat/linux/ +.... + +The output should be similar to the following: + +[.programlisting] +.... +total 30 +lrwxr-xr-x 1 root wheel 7 Apr 11 2018 bin -> usr/bin +drwxr-xr-x 13 root wheel 512 Apr 11 21:10 dev +drwxr-xr-x 25 root wheel 64 Apr 11 21:10 etc +lrwxr-xr-x 1 root wheel 7 Apr 11 2018 lib -> usr/lib +lrwxr-xr-x 1 root wheel 9 Apr 11 2018 lib64 -> usr/lib64 +drwxr-xr-x 2 root wheel 2 Apr 11 21:10 opt +dr-xr-xr-x 1 root wheel 0 Apr 11 21:25 proc +lrwxr-xr-x 1 root wheel 8 Feb 18 02:10 run -> /var/run +lrwxr-xr-x 1 root wheel 8 Apr 11 2018 sbin -> usr/sbin +drwxr-xr-x 2 root wheel 2 Apr 11 21:10 srv +dr-xr-xr-x 1 root wheel 0 Apr 11 21:25 sys +drwxr-xr-x 8 root wheel 9 Apr 11 21:10 usr +drwxr-xr-x 16 root wheel 17 Apr 11 21:10 var .... [[linuxemu-debootstrap]] -== Debian / Ubuntu Base System with man:debootstrap[8] +=== Debian / Ubuntu Base System with debootstrap An alternative way of providing Linux shared libraries is by using package:sysutils/debootstrap[]. This has the advantage of providing a full Debian or Ubuntu distribution. -To use it, follow the instructions at FreeBSD Wiki: https://wiki.freebsd.org/LinuxJails[FreeBSD Wiki - Linux Jails]. -After debootstrapping, man:chroot[8] into the newly created directory and install software in a way typical for the Linux distribution inside, for example: +To install debootstrap execute the following command: [source,shell] .... -# chroot /compat/ubuntu /bin/bash -root@hostname:/# apt update +# pkg install debootstrap .... -It is possible to debootstrap into [.filename]#/compat/linux#, but it is discouraged to avoid collisions with files installed from FreeBSD ports and packages. +man:debootstrap[8] needs man:linux[4] ABI enabled. +Once enabled, execute the following command to install Ubuntu or Debian in [.filename]#/compat/ubuntu#: + +[source,shell] +.... +# debootstrap focal /compat/ubuntu +.... + +[NOTE] +==== +While it is technically possible to install into [.filename]#/compat/linux# instead, it's discouraged due to possible clashes with CentOS-based packages. Instead, derive the directory name from the distribution or version name, e.g., [.filename]#/compat/ubuntu#. -If the bootstrapped instance is intended to provide Linux shared libraries without having to explicitly use chroot or jails, one can point the kernel at it by updating the `compat.linux.emul_path` sysctl and adding a line like this to [.filename]#/etc/sysctl.conf#: +==== + +The output should be similar to the following: [.programlisting] .... -compat.linux.emul_path="/compat/ubuntu" +I: Retrieving InRelease +I: Checking Release signature +I: Valid Release signature (key id F6ECB3762474EDA9D21B7022871920D1991BC93C) +I: Retrieving Packages +I: Validating Packages +I: Resolving dependencies of required packages... +I: Resolving dependencies of base packages... +I: Checking component main on http://archive.ubuntu.com/ubuntu... +[...] +I: Configuring console-setup... +I: Configuring kbd... +I: Configuring ubuntu-minimal... +I: Configuring libc-bin... +I: Configuring ca-certificates... +I: Base system installed successfully. +.... + +Then set up mounts in [.filename]#/etc/fstab#. + +[TIP] +==== +If the contents of the home directory should be shared and to be able to run X11 applications, [.filename]#/home# and [.filename]#/tmp# should be mounted in the linux compat area using man:nullfs[5] for loopback. + +The following example can be added to [.filename]#/etc/fstab#: + +[.programlisting] +.... +# Device Mountpoint FStype Options Dump Pass# +devfs /compat/ubuntu/dev devfs rw,late 0 0 +tmpfs /compat/ubuntu/dev/shm tmpfs rw,late,size=1g,mode=1777 0 0 +fdescfs /compat/ubuntu/dev/fd fdescfs rw,late,linrdlnk 0 0 +linprocfs /compat/ubuntu/proc linprocfs rw,late 0 0 +linsysfs /compat/ubuntu/sys linsysfs rw,late 0 0 +/tmp /compat/ubuntu/tmp nullfs rw,late 0 0 +/home /compat/ubuntu/home nullfs rw,late 0 0 +.... + +Then execute man:mount[8]: + +[source,shell] +.... +# mount -al +.... +==== + +To access the system using man:chroot[8] execute the following command: + +[source,shell] +.... +# chroot /compat/ubuntu /bin/bash .... -This sysctl controls the kernel's path translation mechanism; see man:linux[4] for details. -Please note that changing it might cause trouble for Linux applications installed from FreeBSD packages; one reason is that many of those applications are still 32-bit, while Ubuntu seems to be deprecating 32-bit library support. +Then man:uname[1] can be executed to check the Linux environment: + +[source,shell] +.... +# uname -s -r -m +.... + +The output should be similar to the following: + +[.programlisting] +.... +Linux 3.17.0 x86_64 +.... + +Once inside the chroot, the system behaves as in a normal Ubuntu installation +While systemd doesn't work, the man:service[8] command works as usual. + +[TIP] +==== +To add the package repositories missing from defaults edit the file [.filename]#/compat/ubuntu/etc/apt/sources.list#. + +For amd64 the following example can be used: + +[.programlisting] +.... +deb http://archive.ubuntu.com/ubuntu focal main universe restricted multiverse +deb http://security.ubuntu.com/ubuntu/ focal-security universe multiverse restricted main +deb http://archive.ubuntu.com/ubuntu focal-backports universe multiverse restricted main +deb http://archive.ubuntu.com/ubuntu focal-updates universe multiverse restricted main +.... + +For arm64 this other example can be used: + +[.programlisting] +.... +deb http://ports.ubuntu.com/ubuntu-ports bionic main universe restricted multiverse +.... +==== [[linuxemu-advanced]] == Advanced Topics -The Linux compatibility layer is a work in progress. -Consult https://wiki.freebsd.org/Linuxulator[FreeBSD Wiki - Linuxulator] for more information. - A list of all Linux-related man:sysctl[8] knobs can be found in man:linux[4]. Some applications require specific filesystems to be mounted. -This is normally handled by the [.filename]#/etc/rc.d/linux# script, but can be disabled by adding this line to [.filename]#/etc/rc.conf#: + +This is normally handled by the [.filename]#/etc/rc.d/linux# script but can be disabled at boot executing the following command: [.programlisting] .... -linux_mounts_enable="NO" +sysrc linux_mounts_enable="NO" .... Filesystems mounted by the rc script will not work for Linux processes inside chroots or jails; if needed, configure them in [.filename]#/etc/fstab#: + +[.programlisting] .... devfs /compat/linux/dev devfs rw,late 0 0 tmpfs /compat/linux/dev/shm tmpfs rw,late,size=1g,mode=1777 0 0 @@ -165,7 +311,7 @@ linprocfs /compat/linux/proc linprocfs rw,late 0 0 linsysfs /compat/linux/sys linsysfs rw,late 0 0 .... -Since the Linux binary compatibility layer has gained support for running both 32- and 64-bit Linux binaries (on 64-bit x86 hosts), it is no longer possible to link the emulation functionality statically into a custom kernel. +Since the Linux binary compatibility layer has gained support for running both 32- and 64-bit Linux binaries, it is no longer possible to link the emulation functionality statically into a custom kernel. [[linuxemu-libs-manually]] === Installing Additional Libraries Manually @@ -178,11 +324,18 @@ For base system subdirectories created with man:debootstrap[8], use the instruct If a Linux application complains about missing shared libraries after configuring Linux binary compatibility, determine which shared libraries the Linux binary needs and install them manually. From a Linux system using the same CPU architecture, `ldd` can be used to determine which shared libraries the application needs. + For example, to check which shared libraries `linuxdoom` needs, run this command from a Linux system that has Doom installed: [source,shell] .... % ldd linuxdoom +.... + +The output should be similar to the following: + +[.programlisting] +.... libXt.so.3 (DLL Jump 3.1) => /usr/X11/lib/libXt.so.3.1.0 libX11.so.3 (DLL Jump 3.1) => /usr/X11/lib/libX11.so.3.1.0 libc.so.4 (DLL Jump 4.5pl26) => /lib/libc.so.4.6.29 @@ -190,9 +343,10 @@ libc.so.4 (DLL Jump 4.5pl26) => /lib/libc.so.4.6.29 Then, copy all the files in the last column of the output from the Linux system into [.filename]#/compat/linux# on the FreeBSD system. Once copied, create symbolic links to the names in the first column. + This example will result in the following files on the FreeBSD system: -[source,shell] +[.programlisting] .... /compat/linux/usr/X11/lib/libXt.so.3.1.0 /compat/linux/usr/X11/lib/libXt.so.3 -> libXt.so.3.1.0 @@ -208,7 +362,7 @@ The old one can be removed, as long as the symbolic link points to the new one. For example, these libraries already exist on the FreeBSD system: -[source,shell] +[.programlisting] .... /compat/linux/lib/libc.so.4.6.27 /compat/linux/lib/libc.so.4 -> libc.so.4.6.27 @@ -216,7 +370,7 @@ For example, these libraries already exist on the FreeBSD system: and `ldd` indicates that a binary requires a later version: -[source,shell] +[.programlisting] .... libc.so.4 (DLL Jump 4.5pl26) -> libc.so.4.6.29 .... @@ -224,7 +378,7 @@ libc.so.4 (DLL Jump 4.5pl26) -> libc.so.4.6.29 Since the existing library is only one or two versions out of date in the last digit, the program should still work with the slightly older version. However, it is safe to replace the existing [.filename]#libc.so# with the newer version: -[source,shell] +[.programlisting] .... /compat/linux/lib/libc.so.4.6.29 /compat/linux/lib/libc.so.4 -> libc.so.4.6.29 @@ -236,11 +390,18 @@ After a while, there will be a sufficient set of Linux shared libraries on the s === Branding Linux ELF Binaries The FreeBSD kernel uses several methods to determine if the binary to be executed is a Linux one: it checks the brand in the ELF file header, looks for known ELF interpreter paths and checks ELF notes; finally, by default, unbranded ELF executables are assumed to be Linux anyway. + Should all those methods fail, an attempt to execute the binary might result in error message: [source,shell] .... % ./my-linux-elf-binary +.... + +The output should be similar to the following: + +[.programlisting] +.... ELF binary type not known Abort .... @@ -270,7 +431,7 @@ Note that this will prevent a clean uninstall. If DNS does not work or this error appears: -[source,shell] +[.programlisting] .... resolv+: "bind" is an invalid keyword resolv+: "hosts" is an invalid keyword @@ -285,57 +446,10 @@ multi on .... This specifies that [.filename]#/etc/hosts# is searched first and DNS is searched second. -When [.filename]#/compat/linux/etc/host.conf# does not exist, Linux applications use [.filename]#/etc/host.conf# and complain about the incompatible FreeBSD syntax. +When [.filename]#/compat/linux/etc/host.conf# does not exist, Linux applications use [.filename]#/etc/host.conf# in the host system but they complain since that file does not exist in FreeBSD. Remove `bind` if a name server is not configured using [.filename]#/etc/resolv.conf#. [[linuxemu-misc]] === Miscellaneous -This section describes how Linux binary compatibility works and is based on an email written to {freebsd-chat} by Terry Lambert mailto:tlambert@primenet.com[tlambert@primenet.com] (Message ID: `<199906020108.SAA07001@usr09.primenet.com>`). - -FreeBSD has an abstraction called an "execution class loader". -This is a wedge into the man:execve[2] system call. - -Historically, the UNIX(R) loader examined the magic number (generally the first 4 or 8 bytes of the file) to see if it was a binary known to the system, and if so, invoked the binary loader. - -If it was not the binary type for the system, the man:execve[2] call returned a failure, and the shell attempted to start executing it as shell commands. -The assumption was a default of "whatever the current shell is". - -Later, a hack was made for man:sh[1] to examine the first two characters, and if they were `:\n`, it invoked the man:csh[1] shell instead. - -FreeBSD has a list of loaders, instead of a single loader, with a fallback to the `#!` loader for running shell interpreters or shell scripts. - -For the Linux ABI support, FreeBSD sees the magic number as an ELF binary. -The ELF loader looks for a specialized _brand_, which is a comment section in the ELF image, and which is not present on SVR4/Solaris(TM) ELF binaries. - -For Linux binaries to function, they must be _branded_ as type `Linux` using man:brandelf[1]: - -[source,shell] -.... -# brandelf -t Linux file -.... - -When the ELF loader sees the `Linux` brand, the loader replaces a pointer in the `proc` structure. -All system calls are indexed through this pointer. -In addition, the process is flagged for special handling of the trap vector for the signal trampoline code, and several other (minor) fix-ups that are handled by the Linux kernel module. - -The Linux system call vector contains, among other things, a list of `sysent[]` entries whose addresses reside in the kernel module. - -When a system call is called by the Linux binary, the trap code dereferences the system call function pointer off the `proc` structure, and gets the Linux, not the FreeBSD, system call entry points. - -Linux mode dynamically _reroots_ lookups. -This is, in effect, equivalent to `union` file system mounts. -First, an attempt is made to look up the file in [.filename]#/compat/linux/original-path#. -If that fails, the lookup is done in [.filename]#/original-path#. -This makes sure that binaries that require other binaries can run. -For example, the Linux toolchain can all run under Linux ABI support. -It also means that the Linux binaries can load and execute FreeBSD binaries, if there are no corresponding Linux binaries present, and that a man:uname[1] command can be placed in the [.filename]#/compat/linux# directory tree to ensure that the Linux binaries cannot tell they are not running on Linux. - -In effect, there is a Linux kernel in the FreeBSD kernel. -The various underlying functions that implement all of the services provided by the kernel are identical to both the FreeBSD system call table entries, and the Linux system call table entries: file system operations, virtual memory operations, signal delivery, and System V IPC. -The only difference is that FreeBSD binaries get the FreeBSD _glue_ functions, and Linux binaries get the Linux _glue_ functions. -The FreeBSD _glue_ functions are statically linked into the kernel, and the Linux _glue_ functions can be statically linked, or they can be accessed via a kernel module. - -Technically, this is not really emulation, it is an ABI implementation. -It is sometimes called "Linux emulation" because the implementation was done at a time when there was no other word to describe what was going on. -Saying that FreeBSD ran Linux binaries was not true, since the code was not compiled in. +More information on how binary compatibility works with Linux(R) can be found in the article link:{linux-emulation}[Linux emulation in FreeBSD]. From nobody Wed May 3 22:25:50 2023 X-Original-To: dev-commits-doc-all@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4QBWk70DNCz49L9d for ; Wed, 3 May 2023 22:25:51 +0000 (UTC) (envelope-from git@FreeBSD.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4QBWk66kBxz44BM; Wed, 3 May 2023 22:25:50 +0000 (UTC) (envelope-from git@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1683152750; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=E7WX7U+VmlRy1qHp4Npqy9f2EWl8xpI7tZ/1vBiyhVA=; b=M6D89KL+R3oBL1zRVhQZnr3qYEnmS8dMoIrHMu7OOoupwO22DgNPYjFgU3xBmbTcYptIv7 pOpgSG1qWSP8t5En2poUwG4L5R89kMGGnDU+rneH2zwV8+LnyiNFNAnslBKmewaqQ09YJx dkgY8e+4JrQnbuYnWhN0v6gnBuqrnZwrXQHVwQNAZghWvjZLfbucZxhiKCwFMkXn3vegCH oxgE8DUOec3wQUso0vnLoOFKw56C4YozM4YekcDbRoM5SdkukcXtAFTVMHI3GNy6xzjfeo ay9z9g2ve6qYrl/ZETCyqipVdDNyy8o2jYKzFjXNAqT/35ZeYFTadAMeJTvijg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1683152750; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=E7WX7U+VmlRy1qHp4Npqy9f2EWl8xpI7tZ/1vBiyhVA=; b=ctck6d1Hu8ljp2CWQEm8rmIwO4e8BHksEBuM7v9hs8aBEZMc0CjwGcEwx3CziP+14ofTYi P4j01oHiTi5XwL/0NJftg34msrgnx/OM3x15rT8pqxiPzkjqZrr/9rpgQ5KiSCNpWPuCdU LoOMOmyRc17wG398XJZQwtEYxmHoG1rk6ycR+tHCfHLaXZ2iH/vgvEircJKlskbHtaAKa9 Te1l/YZIUVsiKy4bXXP1UWk9fHatxF66a1X05n9Susih+x1b5IZaGvCdQGvzjOPzpRFg9O w9mo7SBFXHBil/LEkhm1NHwe8ciCiN+dWeuzLGQ22BunBIz/v0sP1kHlmwmqDA== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1683152750; a=rsa-sha256; cv=none; b=wcXf1iqc2CgIJZLEHKw9xNuTzw5uGBKv0N46Kji0KdhS8cfzK8JdvWZUSYzQGJ4Td3kAFR pWebvL8zgM02fAhA9SUmAFd982yBm2yYhBkYPt1Dy6NmHYYAqP+D5Wkqi57sGvtOidpWZX KI95FG3UiK47bfTiT58gfn7uN9VFM1ik7XxzmR+Abk0zyYE7z8J1+mJCyHrOzDDKahqZq4 YLLxNEBl4KbTXpzG1tAaQJxypAvdPvCaFjqFU8NW3SlT4s3U+GoE8LdcQ+wUtRlB245Uj5 B3EsM5UxWRbh5mK973Gn5W+T89kGi+qkT5gHi3HHWw3ve8XmQjjxHTFCbhbxSA== Received: from gitrepo.freebsd.org (gitrepo.freebsd.org [IPv6:2610:1c1:1:6068::e6a:5]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 4QBWk65nHPzn1C; Wed, 3 May 2023 22:25:50 +0000 (UTC) (envelope-from git@FreeBSD.org) Received: from gitrepo.freebsd.org ([127.0.1.44]) by gitrepo.freebsd.org (8.16.1/8.16.1) with ESMTP id 343MPoUn050778; Wed, 3 May 2023 22:25:50 GMT (envelope-from git@gitrepo.freebsd.org) Received: (from git@localhost) by gitrepo.freebsd.org (8.16.1/8.16.1/Submit) id 343MPo2J050777; Wed, 3 May 2023 22:25:50 GMT (envelope-from git) Date: Wed, 3 May 2023 22:25:50 GMT Message-Id: <202305032225.343MPo2J050777@gitrepo.freebsd.org> To: doc-committers@FreeBSD.org, dev-commits-doc-all@FreeBSD.org From: Daniel Ebdrup Jensen Subject: git: e7be269af4 - main - Added missing -u flag to pdbedit List-Id: Commit messages for all branches of the doc repository List-Archive: https://lists.freebsd.org/archives/dev-commits-doc-all List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-dev-commits-doc-all@freebsd.org X-BeenThere: dev-commits-doc-all@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Git-Committer: debdrup X-Git-Repository: doc X-Git-Refname: refs/heads/main X-Git-Reftype: branch X-Git-Commit: e7be269af4a9f1217b8a185f47f4a642194532d4 Auto-Submitted: auto-generated X-ThisMailContainsUnwantedMimeParts: N The branch main has been updated by debdrup: URL: https://cgit.FreeBSD.org/doc/commit/?id=e7be269af4a9f1217b8a185f47f4a642194532d4 commit e7be269af4a9f1217b8a185f47f4a642194532d4 Author: Anthony Bravolisimo AuthorDate: 2023-05-03 21:11:39 +0000 Commit: Daniel Ebdrup Jensen CommitDate: 2023-05-03 22:25:28 +0000 Added missing -u flag to pdbedit --- documentation/content/en/books/handbook/network-servers/_index.adoc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/documentation/content/en/books/handbook/network-servers/_index.adoc b/documentation/content/en/books/handbook/network-servers/_index.adoc index 2d8b9ca286..1bfbbd85a8 100644 --- a/documentation/content/en/books/handbook/network-servers/_index.adoc +++ b/documentation/content/en/books/handbook/network-servers/_index.adoc @@ -2528,7 +2528,7 @@ Map existing FreeBSD user accounts using man:pdbedit[8]: [source,shell] .... -# pdbedit -a username +# pdbedit -a -u username .... This section has only mentioned the most commonly used settings. From nobody Wed May 3 22:37:59 2023 X-Original-To: dev-commits-doc-all@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4QBX0941y7z49LcW for ; Wed, 3 May 2023 22:38:01 +0000 (UTC) (envelope-from debdrup@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2610:1c1:1:6074::16:84]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "freefall.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4QBX093ZKdz45jy for ; Wed, 3 May 2023 22:38:01 +0000 (UTC) (envelope-from debdrup@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1683153481; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=b2HyHDzlQ7tzuuJtLAwAnMA+RVGpgz/meWy0Qtc73j8=; b=FaIt7H6K6Ykjdtm3/OdZQfyd7v6LnlLKNiMR07qyXZFMscB+JQPM90gESXoa24m4+BylQ/ OAdTkopgD6wacUF0mI056SEFEodNbIwp/lDVwNrsTGsM/B0Jx+j9JGhJ2Ns2gLYLrS/3ub xq9BxjrjrNL19pYDTDVWe7PyIfE2EeqXkCnuh7nYlJpegFMVxpd+tsQnpxgoxlVMq5epNb +1iwC1tG3nCMTLabg5o8a0Az1C91Z5qbmKGeunnCrdKQiZEXtgNQLN20LmgW7LhG2ZntRP wAG51ZGz0V13/l7XF+ZXjWxb8NDNscIYFiNCINxY+W7UaFS/Irj3/Tez8WjPYQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1683153481; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=b2HyHDzlQ7tzuuJtLAwAnMA+RVGpgz/meWy0Qtc73j8=; b=SS5K5q91AiFZYezIFlCWA3EKcDsaoXe6P+4e0FnJU3EGpLePxlff+OUTfyt6wZkBRkRzlG g4lHM1TDbtHIJwHfZTT8LjKr1+ZWJ4lEifp0l1uQFXD6IL8nppnsLzbAu0U63k3LtPn6uZ n6EVy9EL3GuP8rhKkbHN5MRuI6RTKOzzRrI7FNAXB/htVePNHRst2D/u5pRPpitRAwiKkh EAeQKNxPKPAAnENoXzAKm5yBMebsSEfQXQUghVL7xE0dQu/cUNgutg0L8ag3+6BNSLzmIL oN1U81DQ11Q36aMcs8Jsm+c1AKhltQIkxggQLdS+s4AVG/RmvTcWyB1ZrAewww== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1683153481; a=rsa-sha256; cv=none; b=Q7LdtFa9TRHa07+B4hfW7talnORYKP5BPlD/7eAUPf11ZXugcwmf6bYEI3oRBTwUNl2+/8 d8/JNQ3zDSL8pXlEDY1CauO1TKOJi7K8wfoI9TE2IYIbfsP20Uvrj6sPphAlGwGJWxhPmk +lisqnFFT2UeODwGQwo/Xa6TGw1kKfYn2hhr/nCdek3ePV76Rio5TYd1RKvdi5I2M8MZ0c 8WtnBbeG6pZIF+5HFOwi1da6CkQNmZ9bnASitjhq6YY4JA+foac10gVr58UvAfYK0R3DI6 f36HXRpsNhTCjtf5dAiU6PQWPlqvyhiw/1u3ADk0U92AuatFKC/adHVIumO9UA== Received: by freefall.freebsd.org (Postfix, from userid 1471) id 5E1BD14743; Wed, 3 May 2023 22:38:01 +0000 (UTC) Date: Thu, 4 May 2023 00:37:59 +0200 From: Daniel Ebdrup Jensen To: dev-commits-doc-all@freebsd.org Subject: Re: git: e7be269af4 - main - Added missing -u flag to pdbedit Message-ID: <20230503223759.54s7hquphe7alddd@geroi.local> Mail-Followup-To: Daniel Ebdrup Jensen , dev-commits-doc-all@freebsd.org References: <202305032225.343MPo2J050777@gitrepo.freebsd.org> List-Id: Commit messages for all branches of the doc repository List-Archive: https://lists.freebsd.org/archives/dev-commits-doc-all List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-dev-commits-doc-all@freebsd.org X-BeenThere: dev-commits-doc-all@freebsd.org MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="z6hqmbm4ndw2xwpa" Content-Disposition: inline In-Reply-To: <202305032225.343MPo2J050777@gitrepo.freebsd.org> X-ThisMailContainsUnwantedMimeParts: N --z6hqmbm4ndw2xwpa Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline On Wed, May 03, 2023 at 10:25:50PM +0000, Daniel Ebdrup Jensen wrote: >The branch main has been updated by debdrup: > >URL: https://cgit.FreeBSD.org/doc/commit/?id=e7be269af4a9f1217b8a185f47f4a642194532d4 > >commit e7be269af4a9f1217b8a185f47f4a642194532d4 >Author: Anthony Bravolisimo >AuthorDate: 2023-05-03 21:11:39 +0000 >Commit: Daniel Ebdrup Jensen >CommitDate: 2023-05-03 22:25:28 +0000 > > Added missing -u flag to pdbedit >--- > documentation/content/en/books/handbook/network-servers/_index.adoc | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > >diff --git a/documentation/content/en/books/handbook/network-servers/_index.adoc b/documentation/content/en/books/handbook/network-servers/_index.adoc >index 2d8b9ca286..1bfbbd85a8 100644 >--- a/documentation/content/en/books/handbook/network-servers/_index.adoc >+++ b/documentation/content/en/books/handbook/network-servers/_index.adoc >@@ -2528,7 +2528,7 @@ Map existing FreeBSD user accounts using man:pdbedit[8]: > > [source,shell] > .... >-# pdbedit -a username >+# pdbedit -a -u username > .... > > This section has only mentioned the most commonly used settings. Hi folks, Sorry, I forgot to add both context and a note about the PR for this commit. According to [1], Samba at some point started requiring the -u flag for adding and removing users from the SAM database. A brief history search through their github repo seems to indicate that it predates a CVS conversion some 20 years back, so it's unclear for how long it's been required. I've added some notes to myself to try and prevent this from happening again. Yours apologetically, Daniel Ebdrup Jensen 1: https://bugs.freebsd.org/270804 --z6hqmbm4ndw2xwpa Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQGTBAABCgB9FiEEDonNJPbg/JLIMoS6Ps5hSHzN87oFAmRS4kdfFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDBF ODlDRDI0RjZFMEZDOTJDODMyODRCQTNFQ0U2MTQ4N0NDREYzQkEACgkQPs5hSHzN 87ofSggAmn8xEaY+eLK1foj5ZDsMVVSu3qimGXKp0htT3X+RZfq5EOSaG/n/lVSS gazgn1PcKaaZof9K0ZPAxYuLmJPNwZtjwLstO8bBlowVsGd2Uhtfu+MtEkkJci0V mschdO1V+pV6mt6LWjcuKsEO6XhKFresvkuukbtnI7a2icWQGq0Wj8tepvH4lFMd Qiuxg2T7J8TjusjUTYNhOycp966016rOd4m8z5cGAvEgPOByRbGqjN0WmhkUG9f/ /SuC5Dz0oqp/uPmewpGkX3YCuj7UACIVeYR2IoNVIFvpJ2jAHR/b3xFLiWv0iedI 1dVVKk6gLSwE8nO4OrjbOQHshfyyzg== =LtuJ -----END PGP SIGNATURE----- --z6hqmbm4ndw2xwpa-- From nobody Thu May 4 00:28:23 2023 X-Original-To: dev-commits-doc-all@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4QBZRW2zmvz49QqR for ; Thu, 4 May 2023 00:28:23 +0000 (UTC) (envelope-from git@FreeBSD.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4QBZRW2Brfz4GrB; Thu, 4 May 2023 00:28:23 +0000 (UTC) (envelope-from git@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1683160103; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=I4IDGN6woubtmqwvCHy092YnMpOpbEDaq5O+/+NECaQ=; b=wecj4zRmO1KxYL5Ah7R1yb3aPGIsQQtpGOi5hIX9VrIdxNAA4GgjRiub7qmSpHJObfJWHl by+bix7D8doy+ygzYEcOKMc9aQkHNvQqQjCBbNVXOH1+/1hZLXuy6guDNZnM3QC3IJSRuc +ZlmiadyAOwCfTtlR0QmlWOPoQSk+PRMtQ+l4w80X05uf1bnOV8klGHXJ5P0p2ViklpJxt rqVMFOhZ/EzqUwN7YUQhZv/u1NdgA5YjJHc7o6DRLk/Lfkr/yIZkl0f13qDPGszjM48w9g lJw1d5mjOiwD8f8bHm9gJ3UlHIqlO9pW48iHKI6sIAQaztKbS+OQ745pf3Eacw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1683160103; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=I4IDGN6woubtmqwvCHy092YnMpOpbEDaq5O+/+NECaQ=; b=BYGPaOiFbn1x4XqoulB0LMdMmF4xXlzY02MFUPKaky6vR/JfVIeQe3NdnN6qqMh1BTMzAS fvO8ApZR4uHAYv9oe7HcGfETWuSfLKu8YEFoK+t1qLb5E5DgK0kdKqKn/DBUN25g37Uy19 aVON32e/qYLEzLnSz5+h8xs9IK9G9vG2So9f6rh2SaLGP/MSvYCJq0Nglu6ze/pbH8/Jrh EtREtI7xgO5GAXFmqhPEF91OT+bqE+ww09Ae0DVyVVb/YppcKvQkFH1HwFOcvl5uW/TB5g i1GHf0zLuV8ny+Qbhh5mWoLe2dnjHvwAIa4zXm/djyI/yQqEIeDxaWxsIYuAZQ== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1683160103; a=rsa-sha256; cv=none; b=YHS+Ck/e2TEc1cpJG8i+BCWs7hvKMyvRRh9QGahQfltLXN04e3coqu/58/H/hwGcIGpuGA uBT9RYh8WCdcN120upBapEF0S2IPUYl4yafE5uvqAiptkPhNf4j1Dgab/jbq/aK5eO9As8 JcFpC0sk+Pz8cbHFA2dDyvJxMQHc1EamhzrRWOpBwF1aaJpBRd/rQKKOYoBJ6oM1o9tERY 62zkr26cdZYy+z+slieWqZ6TOuNrXUxNpa489UJV6YlavV1FvcZVrq7UcEg5mVEMepH2PW s2Jx4Gw7ZBuZon9Q27VtAEfTZgG6Yxh9zONf+44Mvbgay3K7lRANqrHQAx6beQ== Received: from gitrepo.freebsd.org (gitrepo.freebsd.org [IPv6:2610:1c1:1:6068::e6a:5]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 4QBZRW1J0szqrw; Thu, 4 May 2023 00:28:23 +0000 (UTC) (envelope-from git@FreeBSD.org) Received: from gitrepo.freebsd.org ([127.0.1.44]) by gitrepo.freebsd.org (8.16.1/8.16.1) with ESMTP id 3440SNm9048022; Thu, 4 May 2023 00:28:23 GMT (envelope-from git@gitrepo.freebsd.org) Received: (from git@localhost) by gitrepo.freebsd.org (8.16.1/8.16.1/Submit) id 3440SNbo048021; Thu, 4 May 2023 00:28:23 GMT (envelope-from git) Date: Thu, 4 May 2023 00:28:23 GMT Message-Id: <202305040028.3440SNbo048021@gitrepo.freebsd.org> To: doc-committers@FreeBSD.org, dev-commits-doc-all@FreeBSD.org From: Graham Perrin Subject: git: e63798df73 - main - =?utf-8?Q?FreeBSD=20Handbook:=20Config=E2=80=A6=20and=20Tuning:=20corrections?= List-Id: Commit messages for all branches of the doc repository List-Archive: https://lists.freebsd.org/archives/dev-commits-doc-all List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-dev-commits-doc-all@freebsd.org X-BeenThere: dev-commits-doc-all@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Git-Committer: grahamperrin X-Git-Repository: doc X-Git-Refname: refs/heads/main X-Git-Reftype: branch X-Git-Commit: e63798df73d7d956d8c3ce3f81225421fdd1db23 Auto-Submitted: auto-generated X-ThisMailContainsUnwantedMimeParts: N The branch main has been updated by grahamperrin: URL: https://cgit.FreeBSD.org/doc/commit/?id=e63798df73d7d956d8c3ce3f81225421fdd1db23 commit e63798df73d7d956d8c3ce3f81225421fdd1db23 Author: Graham Perrin AuthorDate: 2023-05-04 00:19:20 +0000 Commit: Graham Perrin CommitDate: 2023-05-04 00:19:20 +0000 FreeBSD Handbook: Config… and Tuning: corrections Minor corrections. Names of some mailing lists lacked the 'the' prefix. If referring to an outdated/legacy list archive, without mentioning that it is not current: also, refer to the current archive. One sentence per line should apply to most areas where a question mark is followed by a space. --- .../content/en/books/handbook/config/_index.adoc | 16 ++++++++++------ 1 file changed, 10 insertions(+), 6 deletions(-) diff --git a/documentation/content/en/books/handbook/config/_index.adoc b/documentation/content/en/books/handbook/config/_index.adoc index de68f3fdc3..f157c3c897 100644 --- a/documentation/content/en/books/handbook/config/_index.adoc +++ b/documentation/content/en/books/handbook/config/_index.adoc @@ -672,7 +672,11 @@ For more information, refer to man:hosts[5] and to [.filename]#/usr/share/exampl ==== Troubleshooting When troubleshooting hardware and software configurations, check the simple things first. -Is the network cable plugged in? Are the network services properly configured? Is the firewall configured correctly? Is the NIC supported by FreeBSD? Before sending a bug report, always check the Hardware Notes, update the version of FreeBSD to the latest STABLE version, check the mailing list archives, and search the Internet. +Is the network cable plugged in? +Are the network services properly configured? +Is the firewall configured correctly? +Is the NIC supported by FreeBSD? +Before sending a bug report, always check the Hardware Notes, update the version of FreeBSD to the latest STABLE version, check the mailing list archives, and search the Internet. If the card works, yet performance is poor, read through man:tuning[7]. Also, check the network configuration as incorrect network settings can cause slow connections. @@ -1907,7 +1911,7 @@ acpi_dsdt_name="/boot/DSDT.aml" .... Be sure to copy [.filename]#DSDT.aml# to [.filename]#/boot#, then reboot the system. -If this fixes the problem, send a man:diff[1] of the old and new ASL to {freebsd-acpi} so that developers can work around the buggy behavior in [.filename]#acpica#. +If this fixes the problem, send a man:diff[1] of the old and new ASL to the {freebsd-acpi} so that developers can work around the buggy behavior in [.filename]#acpica#. [[ACPI-submitdebug]] === Getting and Submitting Debugging Info @@ -1941,7 +1945,7 @@ If the required information is triggered by a specific event, such as a suspend Instead, use `sysctl` to specify the layer and level after booting and preparing the system for the specific event. The variables which can be set using `sysctl` are named the same as the tunables in [.filename]#/boot/loader.conf#. -Once the debugging information is gathered, it can be sent to {freebsd-acpi} so that it can be used by the FreeBSD ACPI maintainers to identify the root cause of the problem and to develop a solution. +Once the debugging information is gathered, it can be sent to the {freebsd-acpi} so that it can be used by the FreeBSD ACPI maintainers to identify the root cause of the problem and to develop a solution. [NOTE] ==== @@ -1964,18 +1968,18 @@ When submitting a problem report, include the following information: Substitute the login name for _name_ and manufacturer/model for _system_. For example, use [.filename]#njl-FooCo6000.asl#. -Most FreeBSD developers watch the {freebsd-current}, but one should submit problems to {freebsd-acpi} to be sure it is seen. +Most FreeBSD developers watch the {freebsd-current}, but one should submit problems to the {freebsd-acpi} to be sure it is seen. Be patient when waiting for a response. If the bug is not immediately apparent, submit a bug report. When entering a PR, include the same information as requested above. This helps developers to track the problem and resolve it. -Do not send a PR without emailing {freebsd-acpi} first as it is likely that the problem has been reported before. +Do not send a PR without emailing the {freebsd-acpi} first as it is likely that the problem has been reported before. [[ACPI-References]] === References More information about ACPI may be found in the following locations: -* The FreeBSD ACPI Mailing List Archives (https://lists.freebsd.org/pipermail/freebsd-acpi/[https://lists.freebsd.org/pipermail/freebsd-acpi/]) +* Archives at https://lists.freebsd.org/pipermail/freebsd-acpi/[] and more recent https://lists.freebsd.org/archives/freebsd-acpi/[] * The ACPI 2.0 Specification (http://acpi.info/spec.htm[http://acpi.info/spec.htm]) * man:acpi[4], man:acpi_thermal[4], man:acpidump[8], man:iasl[8], and man:acpidb[8] From nobody Thu May 4 19:03:26 2023 X-Original-To: dev-commits-doc-all@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4QC3B62rk5z49QNP for ; Thu, 4 May 2023 19:03:26 +0000 (UTC) (envelope-from git@FreeBSD.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4QC3B62Wpwz4LFZ; Thu, 4 May 2023 19:03:26 +0000 (UTC) (envelope-from git@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1683227006; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=SiHSd+uwAMTCpQIxX+mkH1hCTOcL2/3lVLHuBIqP+rg=; b=e6OgYI2veJ2FdDJyGWFgDvHjSZls3GU4/3LGgeVL4LpWg2mv3lKu/614hEqw63/0lJJSkL mbKwuZNsQo+uQ4bTpPTPfAaEiZLVvGI9k+OTLjW63ABRT8x4z2YdiY8wSno+4zkJ4l9NOt /2JdXfAsJmdNJS5em6/a0obty0b1uNkbvdkqDmTmK9qgPNp94xb/RmxJXdlcRzi2+18+uL rPXQrgWICS7P+jI0vaKqRqEPkqXUwuoxDOn5TcfMCRBXX3BHDup8hFclvxCiR9GexirlUf jJCwOTvE9WKWuK7cEKv10A4EyuK4+Lq+ycrg/GQcsTqgY6/kMexKwYAKVseyMg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1683227006; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=SiHSd+uwAMTCpQIxX+mkH1hCTOcL2/3lVLHuBIqP+rg=; b=pgou/2ItaJ9IT9dCtHwDAXqyeaRoLrB7pXZLUmHfKO8gkh3RMbiKl0bzpmC0KbWwiLHsTi 6YS+6Gn31Qqf/uDra80MDxPGSxkD/hkKyk18+Tkuam/FZ10JovRc43KANaKFgUk5x0vUWX 8eKwVMRDkZUSnfuq4oOZdhCakkIzEnxzP7Nz/Aq/D+h2iVL/Xq1qSNxu++h9t3uKsDoinL h9cfgfayOTFbkdOobl7SrSpdf3GmfAqOzRZyTtZW/fGgAHBJmhsFnf4ACusradhZt+DdlS YKmxnPybA21Wgv9psp9ArCxLIFDzZFwq5sVb8RK7Ld3XZyvDkmQQT6CmnqIbHA== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1683227006; a=rsa-sha256; cv=none; b=YvmcZv/6q8RWSvDDGnQuutadb440pKbsRHdcXuxItqITWZ8Zfj3Jiz+We8LEJCsvL0AFmb dRSI0wLY0dU9KBp8SX/HbDU97n1auy7a7nV+46jPpQUd6YyOY0hDPKxx4ip2o0Erx+SwVH VRTDlLxIptkrtNW30t6Lh4pXfVcmH6mO9T8Bwfvvaq5+GjP7nE2nsny010c5najp8RT6Wk X68sMLDtyI8iGC/pqaRbVPLfEng63jAeTSmG26LYdDH4jkhxKl85sRt8E1PlgZW7a2ckaR LhPYw09GBeH9hD8TitXC1AxHeGhspd49ImoXavRO3Iu+Vm98jcUXCwtfB0+ijg== Received: from gitrepo.freebsd.org (gitrepo.freebsd.org [IPv6:2610:1c1:1:6068::e6a:5]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 4QC3B61ZlYzP78; Thu, 4 May 2023 19:03:26 +0000 (UTC) (envelope-from git@FreeBSD.org) Received: from gitrepo.freebsd.org ([127.0.1.44]) by gitrepo.freebsd.org (8.16.1/8.16.1) with ESMTP id 344J3Qc1099588; Thu, 4 May 2023 19:03:26 GMT (envelope-from git@gitrepo.freebsd.org) Received: (from git@localhost) by gitrepo.freebsd.org (8.16.1/8.16.1/Submit) id 344J3QEF099587; Thu, 4 May 2023 19:03:26 GMT (envelope-from git) Date: Thu, 4 May 2023 19:03:26 GMT Message-Id: <202305041903.344J3QEF099587@gitrepo.freebsd.org> To: doc-committers@FreeBSD.org, dev-commits-doc-all@FreeBSD.org From: Graham Perrin Subject: git: 64ba076d3e - main - =?utf-8?Q?FreeBSD=20Handbook:=20Config=E2=80=A6:=20ACPI=20Specification?= List-Id: Commit messages for all branches of the doc repository List-Archive: https://lists.freebsd.org/archives/dev-commits-doc-all List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-dev-commits-doc-all@freebsd.org X-BeenThere: dev-commits-doc-all@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Git-Committer: grahamperrin X-Git-Repository: doc X-Git-Refname: refs/heads/main X-Git-Reftype: branch X-Git-Commit: 64ba076d3ea8512996687568097071cecfbc0214 Auto-Submitted: auto-generated X-ThisMailContainsUnwantedMimeParts: N The branch main has been updated by grahamperrin: URL: https://cgit.FreeBSD.org/doc/commit/?id=64ba076d3ea8512996687568097071cecfbc0214 commit 64ba076d3ea8512996687568097071cecfbc0214 Author: Graham Perrin AuthorDate: 2023-05-04 18:52:49 +0000 Commit: Graham Perrin CommitDate: 2023-05-04 18:52:49 +0000 FreeBSD Handbook: Config…: ACPI Specification 2.0 is outdated. acpi.info is not found. Instead: https://uefi.org/specifications#ACPI where version 6.5 is current, and the oldest is 5.0 (Errata B) (released August 2014). --- documentation/content/de/books/handbook/config/_index.adoc | 2 +- documentation/content/el/books/handbook/config/_index.adoc | 2 +- documentation/content/en/books/handbook/config/_index.adoc | 2 +- documentation/content/en/books/handbook/config/_index.po | 3 +-- documentation/content/fr/books/handbook/config/_index.adoc | 2 +- documentation/content/hu/books/handbook/config/_index.adoc | 2 +- documentation/content/it/books/handbook/config/_index.adoc | 2 +- documentation/content/mn/books/handbook/config/_index.adoc | 2 +- documentation/content/nl/books/handbook/config/_index.adoc | 2 +- documentation/content/pl/books/handbook/config/_index.adoc | 2 +- documentation/content/pt-br/books/handbook/config/_index.adoc | 2 +- documentation/content/ru/books/handbook/config/_index.adoc | 2 +- documentation/content/zh-cn/books/handbook/config/_index.adoc | 2 +- documentation/content/zh-tw/books/handbook/config/_index.adoc | 2 +- 14 files changed, 14 insertions(+), 15 deletions(-) diff --git a/documentation/content/de/books/handbook/config/_index.adoc b/documentation/content/de/books/handbook/config/_index.adoc index c3ca5b53f3..3bfdc51759 100644 --- a/documentation/content/de/books/handbook/config/_index.adoc +++ b/documentation/content/de/books/handbook/config/_index.adoc @@ -1523,5 +1523,5 @@ Obwohl die meisten Entwickler die Mailingliste {freebsd-current} lesen, sollten Weitere Informationen über ACPI finden Sie hier: * Die FreeBSD ACPI Mailingliste (https://lists.freebsd.org/pipermail/freebsd-acpi/[https://lists.freebsd.org/pipermail/freebsd-acpi/]) -* Die ACPI 2.0 Spezifikation (http://acpi.info/spec.htm[http://acpi.info/spec.htm]) +* Die https://uefi.org/specifications#ACPI[ACPI Spezifikation] * man:acpi[4], man:acpi_thermal[4], man:acpidump[8], man:iasl[8] und man:acpidb[8] diff --git a/documentation/content/el/books/handbook/config/_index.adoc b/documentation/content/el/books/handbook/config/_index.adoc index 3460bb661d..6449b7545f 100644 --- a/documentation/content/el/books/handbook/config/_index.adoc +++ b/documentation/content/el/books/handbook/config/_index.adoc @@ -1369,6 +1369,6 @@ More information about ACPI may be found in the following locations: * The {freebsd-acpi} * The ACPI Mailing List Archives http://lists.freebsd.org/pipermail/freebsd-acpi/[http://lists.freebsd.org/pipermail/freebsd-acpi/] * The old ACPI Mailing List Archives http://home.jp.FreeBSD.org/mail-list/acpi-jp/[http://home.jp.FreeBSD.org/mail-list/acpi-jp/] -* The ACPI 2.0 Specification http://acpi.info/spec.htm[http://acpi.info/spec.htm] +* The https://uefi.org/specifications#ACPI[ACPI Specification] * FreeBSD Manual pages: man:acpi[4], man:acpi_thermal[4], man:acpidump[8], man:iasl[8], man:acpidb[8] * http://www.cpqlinux.com/acpi-howto.html#fix_broken_dsdt[DSDT debugging resource]. (Uses Compaq as an example but generally useful.) diff --git a/documentation/content/en/books/handbook/config/_index.adoc b/documentation/content/en/books/handbook/config/_index.adoc index f157c3c897..f14ca70e6d 100644 --- a/documentation/content/en/books/handbook/config/_index.adoc +++ b/documentation/content/en/books/handbook/config/_index.adoc @@ -1981,5 +1981,5 @@ Do not send a PR without emailing the {freebsd-acpi} first as it is likely that More information about ACPI may be found in the following locations: * Archives at https://lists.freebsd.org/pipermail/freebsd-acpi/[] and more recent https://lists.freebsd.org/archives/freebsd-acpi/[] -* The ACPI 2.0 Specification (http://acpi.info/spec.htm[http://acpi.info/spec.htm]) +* The https://uefi.org/specifications#ACPI[ACPI Specification] * man:acpi[4], man:acpi_thermal[4], man:acpidump[8], man:iasl[8], and man:acpidb[8] diff --git a/documentation/content/en/books/handbook/config/_index.po b/documentation/content/en/books/handbook/config/_index.po index 5c5e7a167e..1ed5239be1 100644 --- a/documentation/content/en/books/handbook/config/_index.po +++ b/documentation/content/en/books/handbook/config/_index.po @@ -4014,8 +4014,7 @@ msgstr "" #. type: Plain text #: documentation/content/en/books/handbook/config/_index.adoc:1981 msgid "" -"The ACPI 2.0 Specification (http://acpi.info/spec.htm[http://acpi.info/spec." -"htm])" +"The https://uefi.org/specifications#ACPI[ACPI Specification]" msgstr "" #. type: Plain text diff --git a/documentation/content/fr/books/handbook/config/_index.adoc b/documentation/content/fr/books/handbook/config/_index.adoc index 89f66d41a6..76d68d5dcf 100644 --- a/documentation/content/fr/books/handbook/config/_index.adoc +++ b/documentation/content/fr/books/handbook/config/_index.adoc @@ -1359,6 +1359,6 @@ Plus d'information au sujet de l'ACPI peut être trouvé aux emplacements suivan * La liste de diffusion {freebsd-acpi} * Les archives de la liste de diffusion ACPI http://lists.freebsd.org/pipermail/freebsd-acpi/[http://lists.freebsd.org/pipermail/freebsd-acpi/] * Les archives de l'ancienne liste de diffusion ACPI http://home.jp.FreeBSD.org/mail-list/acpi-jp/[http://home.jp.FreeBSD.org/mail-list/acpi-jp/] -* La spécification ACPI 2.0 http://acpi.info/spec.htm[http://acpi.info/spec.htm] +* La https://uefi.org/specifications#ACPI[spécification ACPI] * Les pages de manuel: man:acpi[4], man:acpi_thermal[4], man:acpidump[8], man:iasl[8], man:acpidb[8] * http://www.cpqlinux.com/acpi-howto.html#fix_broken_dsdt[Ressource sur le débogage de la DSDT]. (Utilise un exemple basé sur du matériel Compaq mais qui est en général intéressant.) diff --git a/documentation/content/hu/books/handbook/config/_index.adoc b/documentation/content/hu/books/handbook/config/_index.adoc index 794bc41c38..ea61acd737 100644 --- a/documentation/content/hu/books/handbook/config/_index.adoc +++ b/documentation/content/hu/books/handbook/config/_index.adoc @@ -1406,6 +1406,6 @@ Az ACPI-rõl az alábbi helyeken találunk részletesebb információkat: * A {freebsd-acpi} * Az ACPI levelezési lista archívuma: http://lists.freebsd.org/pipermail/freebsd-acpi/[http://lists.freebsd.org/pipermail/freebsd-acpi/] * A korábbi ACPI levelezési lista archívuma: http://home.jp.FreeBSD.org/mail-list/acpi-jp/[http://home.jp.FreeBSD.org/mail-list/acpi-jp/] -* Az ACPI 2.0 specifikációja: http://acpi.info/spec.htm[http://acpi.info/spec.htm] +* Az https://uefi.org/specifications#ACPI[ACPI specifikációja] * A FreeBSD következõ man oldalai: man:acpi[4], man:acpi_thermal[4], man:acpidump[8], man:iasl[8], man:acpidb[8] * http://www.cpqlinux.com/acpi-howto.html#fix_broken_dsdt[ A DSDT nyomkövetése (angolul)]. (Példának a Compaqot hozza fel, de általánosságban véve hasznos.) diff --git a/documentation/content/it/books/handbook/config/_index.adoc b/documentation/content/it/books/handbook/config/_index.adoc index 5cc5f27092..3944b3599f 100644 --- a/documentation/content/it/books/handbook/config/_index.adoc +++ b/documentation/content/it/books/handbook/config/_index.adoc @@ -1361,6 +1361,6 @@ Maggiori informazioni su ACPI possono essere trovate nei seguenti posti: * La {freebsd-acpi} * Gli archivi della mailing list ACPI http://lists.freebsd.org/pipermail/freebsd-acpi/[http://lists.freebsd.org/pipermail/freebsd-acpi/] * I vecchi archivi della mailing list ACPI http://home.jp.FreeBSD.org/mail-list/acpi-jp/[http://home.jp.FreeBSD.org/mail-list/acpi-jp/] -* La specificazione ACPI 2.0 http://acpi.info/spec.htm[http://acpi.info/spec.htm] +* La https://uefi.org/specifications#ACPI[specificazione ACPI] * Le pagine man di FreeBSD: man:acpi[4], man:acpi_thermal[4], man:acpidump[8], man:iasl[8], man:acpidb[8] * http://www.cpqlinux.com/acpi-howto.html#fix_broken_dsdt[ Le risorse di debugging di DSDT]. (Usa Compaq come esempio ma è sempre utile.) diff --git a/documentation/content/mn/books/handbook/config/_index.adoc b/documentation/content/mn/books/handbook/config/_index.adoc index 8aa7fcdd11..01cb4ed002 100644 --- a/documentation/content/mn/books/handbook/config/_index.adoc +++ b/documentation/content/mn/books/handbook/config/_index.adoc @@ -1454,6 +1454,6 @@ ACPI-ийн талаар дэлгэрэнгүй мэдээллийг дараа * {freebsd-acpi} * ACPI Захидлын Жагсаалтын Архивууд http://lists.freebsd.org/pipermail/freebsd-acpi/[http://lists.freebsd.org/pipermail/freebsd-acpi/] * Хуучин ACPI Захидлын Жагсаалтын Архивууд http://home.jp.FreeBSD.org/mail-list/acpi-jp/[http://home.jp.FreeBSD.org/mail-list/acpi-jp/] -* ACPI 2.0 Тодорхойлолт http://acpi.info/spec.htm[http://acpi.info/spec.htm] +* https://uefi.org/specifications#ACPI[ACPI Тодорхойлолт] * FreeBSD Гарын авлагын хуудаснууд: man:acpi[4], man:acpi_thermal[4], man:acpidump[8], man:iasl[8], man:acpidb[8] * http://www.cpqlinux.com/acpi-howto.html#fix_broken_dsdt[DSDT дибаг эх үүсвэр]. (Compaq-ийг жишээ болгон хэрэглэсэн боловч ерөнхийдөө хэрэгтэй.) diff --git a/documentation/content/nl/books/handbook/config/_index.adoc b/documentation/content/nl/books/handbook/config/_index.adoc index 51268a210f..d817972090 100644 --- a/documentation/content/nl/books/handbook/config/_index.adoc +++ b/documentation/content/nl/books/handbook/config/_index.adoc @@ -1445,6 +1445,6 @@ Meer informatie over ACPI staat op de volgende locaties: * De {freebsd-acpi} * De ACPI mailinglijst archieven http://lists.freebsd.org/pipermail/freebsd-acpi/[http://lists.freebsd.org/pipermail/freebsd-acpi/] * De oude ACPI mailinglijst archieven http://home.jp.FreeBSD.org/mail-list/acpi-jp/[http://home.jp.FreeBSD.org/mail-list/acpi-jp/] -* De ACPI 2.0 specificatie http://acpi.info/spec.htm[http://acpi.info/spec.htm] +* De https://uefi.org/specifications#ACPI[ACPI specificatie] * FreeBSD Handleidingen: man:acpi[4], man:acpi_thermal[4], man:acpidump[8], man:iasl[8], man:acpidb[8] * http://www.cpqlinux.com/acpi-howto.html#fix_broken_dsdt[ DSDT debugging informatie]. (Gebruikt Compaq als voorbeeld, maar van algemeen nut). diff --git a/documentation/content/pl/books/handbook/config/_index.adoc b/documentation/content/pl/books/handbook/config/_index.adoc index 2f7704ba36..d127bf7412 100644 --- a/documentation/content/pl/books/handbook/config/_index.adoc +++ b/documentation/content/pl/books/handbook/config/_index.adoc @@ -1521,5 +1521,5 @@ Most FreeBSD developers watch the {freebsd-current}, but one should submit probl More information about ACPI may be found in the following locations: * The FreeBSD ACPI Mailing List Archives (https://lists.freebsd.org/pipermail/freebsd-acpi/[https://lists.freebsd.org/pipermail/freebsd-acpi/]) -* The ACPI 2.0 Specification (http://acpi.info/spec.htm[http://acpi.info/spec.htm]) +* The https://uefi.org/specifications#ACPI[ACPI Specification] * man:acpi[4], man:acpi_thermal[4], man:acpidump[8], man:iasl[8], and man:acpidb[8] diff --git a/documentation/content/pt-br/books/handbook/config/_index.adoc b/documentation/content/pt-br/books/handbook/config/_index.adoc index 5552030259..e3623f805f 100644 --- a/documentation/content/pt-br/books/handbook/config/_index.adoc +++ b/documentation/content/pt-br/books/handbook/config/_index.adoc @@ -1524,5 +1524,5 @@ A maioria dos desenvolvedores do FreeBSD assina a lista de discussão http://lis Mais informações sobre ACPI podem ser encontradas nos seguintes locais: * Arquivos da lista de e-mail do FreeBSD ACPI (https://lists.freebsd.org/pipermail/freebsd-acpi/[https://lists.freebsd.org/pipermail/freebsd-acpi/]) -* A especificação ACPI 2.0 (http://acpi.info/spec.htm[http://acpi.info/spec.htm]) +* A https://uefi.org/specifications#ACPI[especificação ACPI] * man:acpi[4], man:acpi_thermal[4], man:acpidump[8], man:iasl[8], e man:acpidb[8] diff --git a/documentation/content/ru/books/handbook/config/_index.adoc b/documentation/content/ru/books/handbook/config/_index.adoc index 2ca8b8ac76..a2c2020012 100644 --- a/documentation/content/ru/books/handbook/config/_index.adoc +++ b/documentation/content/ru/books/handbook/config/_index.adoc @@ -1293,6 +1293,6 @@ debug.acpi.level="ACPI_LV_ERROR" * {freebsd-acpi} * Архивы списка рассылки ACPI http://lists.freebsd.org/pipermail/freebsd-acpi/[http://lists.freebsd.org/pipermail/freebsd-acpi/] * Старые архивы списка рассылки ACPI http://home.jp.FreeBSD.org/mail-list/acpi-jp/[http://home.jp.FreeBSD.org/mail-list/acpi-jp/] -* Спецификация ACPI 2.0 http://acpi.info/spec.htm[http://acpi.info/spec.htm] +* https://uefi.org/specifications#ACPI[Спецификация ACPI] * Страницы справочника FreeBSD: man:acpi[4], man:acpi_thermal[4], man:acpidump[8], man:iasl[8], man:acpidb[8] * http://www.cpqlinux.com/acpi-howto.html#fix_broken_dsdt[ Ресурс по отладке DSDT]. (Использует в качестве примера Compaq, но обычно полезен.) diff --git a/documentation/content/zh-cn/books/handbook/config/_index.adoc b/documentation/content/zh-cn/books/handbook/config/_index.adoc index dbfa9ed88d..d9e7751b1b 100644 --- a/documentation/content/zh-cn/books/handbook/config/_index.adoc +++ b/documentation/content/zh-cn/books/handbook/config/_index.adoc @@ -1385,6 +1385,6 @@ debug.acpi.level="ACPI_LV_ERROR" * The {freebsd-acpi} * ACPI 邮件列表存档 http://lists.freebsd.org/pipermail/freebsd-acpi/[http://lists.freebsd.org/pipermail/freebsd-acpi/] * 旧的 ACPI 邮件列表存档 http://home.jp.FreeBSD.org/mail-list/acpi-jp/[http://home.jp.FreeBSD.org/mail-list/acpi-jp/] -* The ACPI 2.0 标准 http://acpi.info/spec.htm[http://acpi.info/spec.htm] +* The https://uefi.org/specifications#ACPI[ACPI 标准] * FreeBSD 手册页: man:acpi[4], man:acpi_thermal[4], man:acpidump[8], man:iasl[8], man:acpidb[8] * http://www.cpqlinux.com/acpi-howto.html#fix_broken_dsdt[DSDT 调试资源]. (使用 Compaq 作为例子但通常情况下都很有用。) diff --git a/documentation/content/zh-tw/books/handbook/config/_index.adoc b/documentation/content/zh-tw/books/handbook/config/_index.adoc index 6a1cc4ef4f..2a3e0912ae 100644 --- a/documentation/content/zh-tw/books/handbook/config/_index.adoc +++ b/documentation/content/zh-tw/books/handbook/config/_index.adoc @@ -1559,5 +1559,5 @@ Most FreeBSD developers watch the http://lists.FreeBSD.org/mailman/listinfo/free More information about ACPI may be found in the following locations: * The FreeBSD ACPI Mailing List Archives (https://lists.freebsd.org/pipermail/freebsd-acpi/[https://lists.freebsd.org/pipermail/freebsd-acpi/]) -* The ACPI 2.0 Specification (http://acpi.info/spec.htm[http://acpi.info/spec.htm]) +* The https://uefi.org/specifications#ACPI[ACPI Specification] * man:acpi[4], man:acpi_thermal[4], man:acpidump[8], man:iasl[8], and man:acpidb[8] From nobody Thu May 4 20:05:48 2023 X-Original-To: dev-commits-doc-all@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4QC4Z46zn7z49TQm for ; Thu, 4 May 2023 20:05:48 +0000 (UTC) (envelope-from git@FreeBSD.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4QC4Z465mhz3GvH; Thu, 4 May 2023 20:05:48 +0000 (UTC) (envelope-from git@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1683230748; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=iGW6WXtfEdhw9DYv1jfseEgiZ2UIonKsjmU7Mx9EV1Q=; b=QslWAFHWaVBb0kxMJpNV5SAhYzA7pyjOpny9JgygZ69gFzprIhc44dSp8eRgsIyPnfs1ML uXNnyFfe8POtaRlu5AHBRhHQwCgLgIAAU4ydQq0mfVdd+yp3HoIcf/PeiTCtXoq5lpvBbz aMGO6tPcoKHF0RSFMluq9TThAiJNCw/YZ/NA+M7PvaYNnGK7gVgT4oyEEPNq4yt5ExQxcq 7qSUlFiylcKb01X4IdDq+1eVae46PMBl07YRYOjSDFPFtwzdNQqaipHTmOf6narx/xKp9/ SjVQasqskWIfXTpanvzl3qW7A7XBcIB+CBUvzV4xNcDooUDUSCtCkYJBp/Pezg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1683230748; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=iGW6WXtfEdhw9DYv1jfseEgiZ2UIonKsjmU7Mx9EV1Q=; b=rgNdC+o0CJfl+kUwqmHfbtmKfRrC93071SxR4712GshA45QNb8hoBmHZ00xQGwxfKdCczv 2oLJ5nNS7v1mKnMDrGhNR8/aPEdXYiTpmeFHwMkztAjXfoYxfMT7mlBqgLvZ5d9xcUvDuQ 0eRbYrXusa8JftrIZ5HxRRS31XjdAdimzVpc/HCyO/RTGEJQ0t0MKT0pIpNtYRNtNVOkuU 3Mt485+kmC0qjJEIcEV3PaNtVXOO+r3bVCz3XOCWPIArOAAmV0JR7UvcAu1pPRS/MDhXfd o4YSBGPSJws7P5srffEcsBLR4SPh4WAsCVA8ZyQbCG6vMiT8fRLdaSq6FmVOBQ== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1683230748; a=rsa-sha256; cv=none; b=AdIkCvAPEWs2MK+nEPZLTNZxuEZ9eOYunLLF2/ZFhq52Z0PUvB/ejnqQuogbodbZ9KxpiD lqCZeM5IF09AsVa+8cCrDwhda0yyYCa84otym8KtjZ/Ubiuouq3NqpD9TOdjkYged0JLLP oOhBsUB2lOD8i/rNukhwMnKqsrqZvToDuDEofuktgXumB6+9VVEKJryVQQarPBLfAJpnhL /NzAKNzWTMWnMqqIMgt28M+uVjnCC0e4z4kK2btsHuHJIw0yvbYQG4N5WXIwU9PTid/udN qi8+wZBNhX9iqmc3uJEECRsoKNf6b8dRlyF7fkGHyHTm1EkCymG7coAChdD04w== Received: from gitrepo.freebsd.org (gitrepo.freebsd.org [IPv6:2610:1c1:1:6068::e6a:5]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 4QC4Z44sN5zQgw; Thu, 4 May 2023 20:05:48 +0000 (UTC) (envelope-from git@FreeBSD.org) Received: from gitrepo.freebsd.org ([127.0.1.44]) by gitrepo.freebsd.org (8.16.1/8.16.1) with ESMTP id 344K5muj000504; Thu, 4 May 2023 20:05:48 GMT (envelope-from git@gitrepo.freebsd.org) Received: (from git@localhost) by gitrepo.freebsd.org (8.16.1/8.16.1/Submit) id 344K5mwj000503; Thu, 4 May 2023 20:05:48 GMT (envelope-from git) Date: Thu, 4 May 2023 20:05:48 GMT Message-Id: <202305042005.344K5mwj000503@gitrepo.freebsd.org> To: doc-committers@FreeBSD.org, dev-commits-doc-all@FreeBSD.org From: Edson Brandi Subject: git: c769bddba1 - main - Article geom-class translated to pt_BR and synced with doc tree version 98c736dd127a2096dc08252d1082300f2ec28ab5 List-Id: Commit messages for all branches of the doc repository List-Archive: https://lists.freebsd.org/archives/dev-commits-doc-all List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-dev-commits-doc-all@freebsd.org X-BeenThere: dev-commits-doc-all@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Git-Committer: ebrandi X-Git-Repository: doc X-Git-Refname: refs/heads/main X-Git-Reftype: branch X-Git-Commit: c769bddba1509db099fe62e74fd4f5d317dbcc0d Auto-Submitted: auto-generated X-ThisMailContainsUnwantedMimeParts: N The branch main has been updated by ebrandi: URL: https://cgit.FreeBSD.org/doc/commit/?id=c769bddba1509db099fe62e74fd4f5d317dbcc0d commit c769bddba1509db099fe62e74fd4f5d317dbcc0d Author: Edson Brandi AuthorDate: 2023-05-04 20:04:54 +0000 Commit: Edson Brandi CommitDate: 2023-05-04 20:04:54 +0000 Article geom-class translated to pt_BR and synced with doc tree version 98c736dd127a2096dc08252d1082300f2ec28ab5 --- .../content/pt-br/articles/geom-class/_index.adoc | 177 +-- .../content/pt-br/articles/geom-class/_index.po | 1397 ++++++++++++++++++++ 2 files changed, 1487 insertions(+), 87 deletions(-) diff --git a/documentation/content/pt-br/articles/geom-class/_index.adoc b/documentation/content/pt-br/articles/geom-class/_index.adoc index e108fc373c..f05d77126f 100644 --- a/documentation/content/pt-br/articles/geom-class/_index.adoc +++ b/documentation/content/pt-br/articles/geom-class/_index.adoc @@ -1,8 +1,11 @@ --- -title: Escrevendo uma classe GEOM authors: - - author: Ivan Voras + - + author: 'Ivan Voras' email: ivoras@FreeBSD.org +description: 'Um guia sobre os internals do GEOM e sobre como escrever sua própria classe GEOM' +tags: ["GEOM", "kernel", "modules", "FreeBSD"] +title: 'Escrevendo uma classe GEOM' trademarks: ["freebsd", "intel", "general"] --- @@ -40,7 +43,7 @@ endif::[] [.abstract-title] Resumo -Este texto documenta alguns pontos de partida no desenvolvimento de classes GEOM e módulos do kernel em geral. Supõe-se que o leitor esteja familiarizado com a programação C do userland. +Este texto documenta alguns pontos de partida no desenvolvimento de classes GEOM e módulos de kernel em geral. Pressupõe-se que o leitor esteja familiarizado com a programação de espaço de usuário em C. ''' @@ -52,27 +55,27 @@ toc::[] [[intro-docs]] === Documentação -A documentação sobre programação do kernel é escassa - é uma das poucas áreas na qual não há quase nada de tutoriais amigáveis, e a frase "usa a fonte!" realmente é verdadeira. No entanto, existem alguns pedaços (alguns deles seriamente desatualizados) flutuando por ai e que devem ser estudados antes de começar a codificar: +A documentação sobre programação de kernel é escassa - é uma das poucas áreas em que quase não há tutoriais amigáveis, e a frase "use o código fonte!" realmente é verdadeira. No entanto, existem alguns fragmentos (alguns deles seriamente desatualizados) circulando que devem ser estudados antes de começar a codificar: -* O extref:{developers-handbook}[Manual do Desenvolvedor do FreeBSD] - parte do projeto de documentação, ele não contém nenhum informação específica para a programação do kernel, mas possui algumas informações gerais úteis. -* O extref:{arch-handbook}[Manual de Arquitetura do FreeBSD] - também do projeto de documentação, contém descrições de várias instalações e procedimentos de baixo nível. O capítulo mais importante é o 13, extref:{arch-handbook}[Escrevendo drivers de dispositivo FreeBSD, driverbasics]. -* A seção Blueprints do site do http://www.freebsddiary.org[FreeBSD Diary] contém vários artigos interessantes sobre os recursos do kernel. -* As páginas de manual na seção 9 - para documentação importante sobre as funções do kernel. -* A página man man:geom[4] e os http://phk.freebsd.dk/pubs/[Slides sobre o GEOM de PHK] - para uma introdução geral do subsistema GEOM. -* Páginas de manual man:g_bio[9], man:g_event[9], man:g_data[9], man:g_geom[9], man:g_provider[9] man:g_consumer[9], man:g_access[9] & outros ligados a partir deles, para documentação sobre funcionalidades específicas. -* A página do manual man:style[9] - para documentação sobre as convenções de estilo de codificação que devem ser seguidas para qualquer código que se destine a ser incorporado à Árvore do Subversion do FreeBSD. +* O extref:{developers-handbook}[Handbook do Desenvolvedor do FreeBSD] - parte do projeto de documentação, não contém nada específico sobre programação do kernel, mas sim algumas informações úteis em geral. +* O extref:{arch-handbook}[Handbook de Arquitetura do FreeBSD] - também do projeto de documentação, contém descrições de várias instalações e procedimentos de baixo nível. O capítulo mais importante é o 13, extref:{arch-handbook}[Escrevendo drivers de dispositivos FreeBSD, driverbasics]. +* A seção Blueprints do site http://www.freebsddiary.org contém vários artigos interessantes sobre as facilidades do kernel. +* As páginas de manual da seção 9 - para documentação importante sobre as funções do kernel. +* A página de manual man:geom[4] e os slides sobre o GEOM do PHK em http://phk.freebsd.dk/pubs/ - para uma introdução geral ao subsistema GEOM. +* As páginas de manual man:g_bio[9], man:g_event[9], man:g_data[9], man:g_geom[9], man:g_provider[9], man:g_consumer[9], man:g_access[9] e outras vinculadas a elas, para documentação sobre funcionalidades específicas. +* A página de manual man:style[9] - para documentação sobre as convenções de estilo de codificação que devem ser seguidas para qualquer código que seja commitado para a árvore do FreeBSD. [[prelim]] == Preliminares -A melhor maneira de fazer o desenvolvimento do kernel é ter (pelo menos) dois computadores separados. Um deles conteria o ambiente de desenvolvimento e o código fonte, e o outro seria usado para testar o código recém escrito, inicializando por meio da rede e montando seu sistema de arquivo a partir do primeiro computador. Desta forma, se o novo código contiver erros e travar a máquina, isso não irá atrapalhar o código fonte (e nem nenhum outros dado "vivo"). O segundo sistema nem sequer requer um monitor adequado. Em vez disso, ele pode ser conectado por meio de um cabo serial ou KVM ao primeiro computador. +A melhor maneira de desenvolver para o kernel é ter (pelo menos) dois computadores separados. Um deles conteria o ambiente de desenvolvimento e as fontes, e o outro seria usado para testar o código recém-escrito por meio do boot e montagem de sistemas de arquivos por rede do primeiro. Dessa forma, se o novo código contiver erros e travar a máquina, ele não afetará as fontes (e outros dados "ao vivo"). O segundo sistema nem mesmo precisa de uma tela adequada. Em vez disso, ele pode ser conectado com um cabo serial ou KVM para o primeiro. -Mas, como nem todo mundo tem dois ou mais computadores à mão, há algumas coisas que podem ser feitas para preparar um sistema "vivo " para desenvolver código para o kernel. Esta configuração também é aplicável para desenvolvimento em uma máquina virtual criada com o http://www.vmware.com/[VMWare] ou com o http://www.qemu.org/[QEmu] (a próxima melhor coisa depois de uma máquina de desenvolvimento dedicada). +No entanto, como nem todo mundo tem dois ou mais computadores disponíveis, existem algumas coisas que podem ser feitas para preparar um sistema "ao vivo" para o desenvolvimento de código do kernel. Essa configuração também é aplicável para desenvolvimento em uma máquina virtual http://www.vmware.com/[VMWare] ou http://www.qemu.org/[QEmu] (a próxima melhor opção depois de uma máquina de desenvolvimento dedicada). [[prelim-system]] === Modificando um sistema para desenvolvimento -Para qualquer programação do kernel, um kernel com a opção `INVARIANTS` ativada é obrigatório. Então, digite estas linhas no seu arquivo de configuração do kernel: +Para qualquer programação de kernel, é essencial ter um kernel com `INVARIANTS` ativado. Portanto, adicione as seguintes opções no arquivo de configuração do kernel: [.programlisting] .... @@ -80,7 +83,7 @@ options INVARIANT_SUPPORT options INVARIANTS .... -Para ter um maior nível de depuração, você também devrá incluir o suporte ao WITNESS, o qual irá alertá-lo sobre erros relacionados a bloqueios (locking): +Para obter mais depuração, você também deve incluir o suporte a WITNESS, que alertará sobre erros de bloqueio: [.programlisting] .... @@ -88,16 +91,16 @@ options WITNESS_SUPPORT options WITNESS .... -Para depurar despejos de memória, é necessário um kernel com símbolos de depuração: +Para depurar despejos de falhas (crash dumps), é necessário um kernel com símbolos de depuração: [.programlisting] .... makeoptions DEBUG=-g .... -Com a maneira usual de instalar o kernel (`make installkernel`) o kernel de depuração não será instalado automaticamente. Ele é chamado de [.filename]#kernel.debug# e fica localizado em [.filename]#/usr/obj/usr/src/sys/KERNELNAME/#. Por conveniência, deve ser copiado para [.filename]#/boot/kernel/#. +Com a maneira usual de instalar o kernel (`make installkernel`), o kernel de depuração não será instalado automaticamente. Ele é chamado de [.filename]#kernel.debug# e fica localizado em [.filename]#/usr/obj/usr/src/sys/NOME_DO_KERNEL/#. Por conveniência, ele deve ser copiado para [.filename]#/boot/kernel/#. -Outra conveniência é habilitar o depurador do kernel para que você possa examinar o panic do kernel quando isso acontece. Para isso, insira as seguintes linhas no seu arquivo de configuração do kernel: +Outra conveniência é habilitar o depurador do kernel para que você possa examinar um kernel panic quando ele ocorrer. Para isso, adicione as seguintes linhas no arquivo de configuração do kernel: [.programlisting] .... @@ -113,7 +116,7 @@ Para que isso funcione, você pode precisar definir um sysctl (se ele não estiv debug.debugger_on_panic=1 .... -Kernel panics acontecerão, portanto, deve-se ter cuidado com o cache do sistema de arquivos. Em particular, ter o softupdates habilitado pode significar que a versão mais recente do arquivo pode ser perdida se um panic ocorrer antes de ser committed para armazenamento. Desativar o softupdates produz um grande impacto na performance e ainda não garante a consistência dos dados. A montagem do sistema de arquivos com a opção "sync" é necessária para isso. Para um compromisso, os atrasos do cache de softupdates podem ser encurtados. Existem três sysctl's que são úteis para isso (melhor ser configurado em [.filename]#/etc/sysctl.conf#): +Panics do kernel podem acontecer, portanto, é preciso ter cuidado com o cache do sistema de arquivos. Em particular, ter softupdates pode significar que a versão mais recente de um arquivo pode ser perdida se ocorrer um panic antes que seja gravada no armazenamento. Desabilitar o softupdates implica em uma grande perda de desempenho e ainda não garante a consistência dos dados. É necessário montar o sistema de arquivos com a opção "sync" para garantir isso. Como um compromisso, os atrasos do cache do softupdates podem ser encurtados. Existem três sysctl que são úteis para isso (melhor configurados em [.filename]#/etc/sysctl.conf#): [.programlisting] .... @@ -124,7 +127,7 @@ kern.metadelay=3 Os números representam segundos. -Para depurar os panics do kernel, os dumps do núcleo do kernel são necessários. Como um kernel panic pode tornar os sistemas de arquivos inutilizáveis, esse despejo de memória é primeiramente gravado em uma partição bruta. Normalmente, esta é a partição de swap. Essa partição deve ser pelo menos tão grande quanto a RAM física na máquina. Na próxima inicialização, o despejo é copiado para um arquivo normal. Isso acontece depois que os sistemas de arquivos são verificados e montados e antes que o swap seja ativado. Isto é controlado com duas variáveis [.filename]#/etc/rc.conf#: +Para depurar panics do kernel, são necessários os despejos de núcleo do kernel. Como um kernel panic pode tornar os sistemas de arquivos inutilizáveis, este despejo de falhas é primeiro gravado em uma partição raw. Geralmente, isso é feito na partição de swap. Esta partição deve ter pelo menos o tamanho da RAM física da máquina. No próximo boot, o despejo é copiado para um arquivo regular. Isso acontece após a verificação e montagem dos sistemas de arquivos e antes que o swap seja ativado. Isso é controlado com duas variáveis do arquivo [.filename]#/etc/rc.conf#: [.programlisting] .... @@ -132,35 +135,35 @@ dumpdev="/dev/ad0s4b" dumpdir="/usr/core .... -A variável `dumpdev` especifica a partição de swap e `dumpdir` informa ao sistema onde no sistema de arquivos ele deverá realocar o dump principal na reinicialização. +A variável `dumpdev` especifica a partição de swap e `dumpdir` informa ao sistema onde no sistema de arquivos realocar o core dump no reboot. -A gravação de core dumps é lenta e leva muito tempo, então se você tiver muita memória (>256M) e muitos panics, pode ser frustrante sentar e esperar enquanto isso é feito (duas vezes - primeiro para gravar para o swap, depois para realocá-lo para o sistema de arquivos). É conveniente limitar a quantidade de RAM que o sistema usará através de uma variável do [.filename]#/boot/loader.conf#: +Gravar o core dump do kernel é lento e leva muito tempo, portanto, se você tiver muita memória (>256 MB) e muitos panics, pode ser frustrante esperar enquanto isso é feito (duas vezes - primeiro para gravá-lo na troca, depois para realocá-lo no sistema de arquivos). É conveniente, portanto, limitar a quantidade de RAM que o sistema usará por meio de um ajuste no [.filename]#/boot/loader.conf#: [.programlisting] .... hw.physmem="256M" .... -Se os panics são frequentes e os sistemas de arquivos são grandes (ou você simplesmente não confia em softupdates + background fsck), é aconselhável desligar o fsck em background através da variável [.filename]#/etc/rc.conf#: +Se os panics forem frequentes e os sistemas de arquivos forem grandes (ou se você simplesmente não confiar no softupdates + fsck em segundo plano), é aconselhável desativar o fsck em segundo plano por meio da seguinte variável no arquivo [.filename]#/etc/rc.conf#: [.programlisting] .... background_fsck="NO" .... -Dessa forma, os sistemas de arquivos sempre serão verificados quando necessário. Observe que, com o fsck em segundo plano, um novo panic pode acontecer enquanto ele está verificando os discos. Novamente, a maneira mais segura é não ter muitos sistemas de arquivos locais, usando o outro computador como um servidor NFS. +Dessa forma, os sistemas de arquivos serão sempre verificados quando necessário. Observe que, com o fsck em segundo plano, um novo panic pode ocorrer enquanto os discos estão sendo verificados. Novamente, a maneira mais segura é não ter muitos sistemas de arquivos locais, usando outro computador como um servidor NFS. [[prelim-starting]] === Começando o projeto -Para o propósito de criar uma nova classe GEOM, um subdiretório vazio deve ser criado sob um diretório arbitrário acessível pelo usuário. Você não precisa criar o diretório do módulo em [.filename]#/usr/src#. +Para criar uma nova classe GEOM, um subdiretório vazio deve ser criado em um diretório arbitrário acessível pelo usuário. Você não precisa criar o diretório do módulo em [.filename]#/usr/src#. [[prelim-makefile]] === O Makefile -É uma boa prática criar [.filename]#Makefiles# para cada projeto de codificação não trivial, o que obviamente inclui módulos do kernel. +É uma boa prática criar arquivos [.filename]#Makefile# para todos os projetos de codificação não triviais, o que inclui, é claro, módulos do kernel. -Criar o [.filename]#Makefile# é simples graças a um extenso conjunto de rotinas auxiliares fornecidas pelo sistema. Em suma, aqui está um exemplo de como um Makefile [.filename]#mínimo# para um módulo do kernel se parece: +Criar o arquivo [.filename]#Makefile# é simples graças a um extenso conjunto de rotinas auxiliares fornecidas pelo sistema. Em resumo, aqui está como um [.filename]#Makefile# mínimo se parece para um módulo do kernel: [.programlisting] .... @@ -170,7 +173,7 @@ KMOD=geom_journal .include .... -Este [.filename]#Makefile# (com nomes de arquivos alterados) serve para qualquer módulo do kernel, e uma classe GEOM pode residir em apenas um módulo do kernel. Se mais de um arquivo for necessário, liste-o na variável `SRCS`, separado com espaço em branco de outros nomes de arquivos. +Este [.filename]#Makefile# (com nomes de arquivo alterados) serve para qualquer módulo do kernel e uma classe GEOM pode residir em apenas um módulo do kernel. Se mais de um arquivo for necessário, liste-os na variável `SRCS`, separados por espaço de outros nomes de arquivo. [[kernelprog]] == Programação do kernel do FreeBSD @@ -178,34 +181,34 @@ Este [.filename]#Makefile# (com nomes de arquivos alterados) serve para qualquer [[kernelprog-memalloc]] === Alocação de memória -Veja o man:malloc[9]. A alocação básica de memória é apenas ligeiramente diferente do seu userland equivalente. Mais notavelmente, `malloc`() e `free`() aceitam parâmetros adicionais conforme descrito na página do manual. +Consulte man:malloc[9]. A alocação básica de memória é apenas ligeiramente diferente da sua equivalente no espaço do usuário. Mais notavelmente, `malloc()` e `free()` aceitam parâmetros adicionais conforme descrito na página do manual. -Um "malloc type" deve ser declarado na seção de declaração de um arquivo fonte, assim: +Um "malloc type" deve ser declarado na seção de declaração de um arquivo de código fonte, por exemplo desta forma: [.programlisting] .... static MALLOC_DEFINE(M_GJOURNAL, "gjournal data", "GEOM_JOURNAL Data"); .... -Para usar esta macro, os cabeçalhos [.filename]#sys/param.h#, [.filename]#sys/kernel.h# e [.filename]#sys/malloc.h# devem ser incluídos. +Para usar essa macro, os cabeçalhos [.filename]#sys/param.h#, [.filename]#sys/kernel.h# e [.filename]#sys/malloc.h# devem ser incluídos. -Existe outro mecanismo para alocar memória, o UMA (Universal Memory Allocator). Veja man:uma[9] para detalhes, mas ele é um tipo especial de alocador usado principalmente para alocação rápida de listas compostas de itens do mesmo tamanho (por exemplo, matrizes dinâmicas de estruturas). +Existe outro mecanismo para alocar memória, o UMA (Universal Memory Allocator). Consulte man:uma[9] para obter detalhes, mas é um tipo especial de alocador usado principalmente para alocação rápida de listas compostas por itens do mesmo tamanho (por exemplo, matrizes dinâmicas de estruturas). [[kernelprog-lists]] === Listas e filas -Veja man:queue[3]. Há MUITOS casos quando uma lista de coisas precisa ser mantida. Felizmente, essa estrutura de dados é implementada (de várias maneiras) por macros C incluídas no sistema. O tipo de lista mais usado é o TAILQ, porque é o mais flexível. É também aquele com os maiores requisitos de memória (seus elementos são duplamente vinculados) e também o mais lento (embora a variação de velocidade seja mais da ordem de várias instruções da CPU, portanto, ela não deve ser levada a sério). +Consulte man:queue[3]. Existem MUITOS casos em que uma lista de coisas precisa ser mantida. Felizmente, essa estrutura de dados é implementada (de várias maneiras) por macros em C incluídas no sistema. O tipo de lista mais usado é TAILQ porque é o mais flexível. Também é o que tem os maiores requisitos de memória (seus elementos são duplamente vinculados) e também o mais lento (embora a variação de velocidade seja da ordem de algumas instruções de CPU a mais, então não deve ser levado a sério). -Se a velocidade de recuperação de dados for muito importante, veja man:tree[3] e man:hashinit[9]. +Se a velocidade de recuperação de dados é muito importante, consulte man:tree[3] e man:hashinit[9]. [[kernelprog-bios]] === BIOS -A estrutura `bio` é usada para todas e quaisquer operações de Input/Output relativas ao GEOM. Ele basicamente contém informações sobre qual dispositivo ('provedor') deve satisfazer a solicitação, tipo de pedido, offset, comprimento, ponteiro para um buffer e um monte de sinalizadores "específicos do usuário" e campos que podem ajudar a implementar vários hacks. +A estrutura `bio` é usada para todas e quaisquer operações de entrada/saída relacionadas ao GEOM. Basicamente, ela contém informações sobre qual dispositivo ('provider') deve satisfazer a solicitação, tipo de solicitação, deslocamento, comprimento, ponteiro para um buffer e um conjunto de flags e campos "específicos do usuário" que podem ajudar a implementar vários ajustes. -O importante aqui é que os `bio`-s são tratados de forma assíncrona. Isso significa que, na maior parte do código, não há nenhum análogo as chamadas man:read[2] e man:write[2] que não retornam até que uma solicitação seja feita. Em vez disso, uma função fornecida pelo desenvolvedor é chamada como uma notificação quando a solicitação é concluída (ou resulta em erro). +O importante aqui é que os ``bio``s são manipulados de forma assíncrona. Isso significa que, na maioria das partes do código, não há um análogo das chamadas man:read[2] e man:write[2] do espaço do usuário que não retornam até que uma solicitação seja concluída. Em vez disso, uma função fornecida pelo desenvolvedor é chamada como uma notificação quando a solicitação é concluída (ou resulta em erro). -O modelo de programação assíncrona (também chamado de "orientado a eventos") é um pouco mais difícil do que o imperativo muito mais usado no userland (pelo menos leva um tempo para se acostumar com isso). Em alguns casos, as rotinas auxiliares `g_write_data`() e `g_read_data`() podem ser usadas, mas __nem sempre__. Em particular, elas não podem ser usadas quando um mutex é mantido; por exemplo, o mutex de topologia GEOM ou o mutex interno mantido durante as funções `.start`() e `.stop`(). +O modelo de programação assíncrono (também chamado de "event-driven") é um pouco mais difícil do que o muito usado modelo imperativo usado no espaço do usuário (pelo menos leva um tempo para se acostumar). Em alguns casos, as rotinas auxiliares `g_write_data()` e `g_read_data()` podem ser usadas, mas __nem sempre__. Em particular, elas não podem ser usadas quando um mutex é mantido; por exemplo, o mutex de topologia GEOM ou o mutex interno mantido durante as funções `.start()` e `.stop()`. [[geom]] == Programação GEOM @@ -218,15 +221,15 @@ Se o desempenho máximo não for necessário, uma maneira muito mais simples de [[geom-class]] === Classe GEOM -Classes GEOM são transformações nos dados. Essas transformações podem ser combinadas em uma forma de árvore. Instâncias de classes GEOM são chamadas de __geoms__. +As classes GEOM são transformações nos dados. Essas transformações podem ser combinadas de maneira semelhante a uma árvore. As instâncias de classes GEOM são chamadas de __geoms__. -Cada classe GEOM possui vários "métodos de classe" que são chamados quando não há nenhuma instância geom disponível (ou simplesmente não estão vinculados a uma única instância): +Cada classe GEOM tem vários "métodos de classe" que são chamados quando não há uma instância geom disponível (ou simplesmente não estão vinculados a uma única instância): -* `.init` é chamada quando o GEOM toma conhecimento de uma classe GEOM (quando o módulo do kernel é carregado). -* `.fini` é chamada quando o GEOM abandona a classe (quando o módulo é descarregado) -* `.taste` é chamada next, uma vez para cada provedor que o sistema tiver disponível. Se aplicável, essa função geralmente criará e iniciará uma instância geom. -* `.destroy_geom` é chamada quando o geom deve ser desfeito -* `.ctlconf` é chamado quando o usuário solicita a reconfiguração do geom existente +* O `.init` é chamado quando o GEOM toma conhecimento de uma classe GEOM (quando o módulo do kernel é carregado.) +* O `.fini` é chamado quando o GEOM abandona a classe (quando o módulo é descarregado) +* O `.taste` é chamado em seguida, uma vez para cada provider que o sistema tem disponível. Se aplicável, esta função geralmente criará e iniciará uma instância geom. +* O `.destroy_geom` é chamado quando o geom deve ser desmontado +* O `.ctlconf` é chamado quando o usuário solicita a reconfiguração do geom existente Também são definidas as funções de evento GEOM, que serão copiadas para a instância geom. @@ -237,13 +240,13 @@ Estas funções são chamadas a partir da thread g_event do kernel. [[geom-softc]] === Softc -O nome "softc" é um termo legado para "dados privados do driver". O nome provavelmente vem do termo arcaico "bloco de controle de software". No GEOM, ele é uma estrutura (mais precisamente: ponteiro para uma estrutura) que pode ser anexada a uma instância geom para armazenar quaisquer dados que sejam privados para a instância geom. A maioria das classes GEOM possui os seguintes membros: +O nome "softc" é um termo legado para "dados privados do driver". O nome provavelmente vem do termo arcaico "bloco de controle de software". No GEOM, é uma estrutura (mais precisamente, um ponteiro para uma estrutura) que pode ser anexada a uma instância geom para manter quaisquer dados que sejam privados à instância geom. A maioria das classes GEOM tem os seguintes membros: -* `struct g_provider *provider` : O "provedor" que este geom instância -* `uint16_t n_disks` : Número de consumidores que este geom consome -* `struct g_consumer \**disks`: Array de `struct g_consumer*`. (Não é possível usar apenas uma única via indireta porque o struct g_consumer* é criado em nosso nome pela GEOM). +* `struct g_provider *provider`: Instância geom criada a partir do provider correspondente +* `uint16_t n_disks`: Número de consumidores que esta instância geom consome +* `struct g_consumer \**disks`: Array de `struct g_consumer*`. (Não é possível usar apenas uma única indireção porque os `struct g_consumer*` são criados em nosso nome pelo GEOM). -A estrutura `softc` contém todo o estado da instância geom. Cada instância geom possui seu próprio softc. +A estrutura `softc` contém todo o estado da instância geom. Cada instância geom tem sua própria estrutura `softc`. [[geom-metadata]] === Metadados @@ -264,22 +267,22 @@ Os metadados estão localizados no último setor do provedor (e, portanto, devem A sequência de eventos é: -* o usuário chama o utilitário man:geom[8] (ou um de seus equivalentes hardlinked) -* o utilitário descobre qual classe geom ele é suposto manipular e procura pela biblioteca [.filename]#geom_CLASSNAME.so# (geralmente em [.filename]#/lib/geom#). -* ele man:dlopen[3]-s a biblioteca, extrai as definições dos parâmetros da linha de comandos e funções auxiliares. +* O usuário chama o utilitário man:geom[8] (ou um comandos alternativos para o mesmo utilitário) +* O utilitário determina qual classe geom ele deve manipular e procura pela biblioteca [.filename]#geom_CLASSNAME.so# (geralmente em [.filename]#/lib/geom#). +* O utilitário utiliza a função man:dlopen[3] para carregar dinamicamente a biblioteca, extrair as definições dos parâmetros de linha de comando e funções auxiliares. No caso da criação/rotulação de um novo geom, isso é o que acontece: -* O man:geom[8] procura no argumento da linha de comando pelo comando (geralmente `label`) e chama uma função auxiliar . +* O comando man:geom[8] procura na linha de comando pelo comando (geralmente `label`) e chama uma função auxiliar correspondente. * A função auxiliar verifica parâmetros e reúne metadados, que são gravados em todos os provedores envolvidos. -* Este "estraga" geoms existentes (se existirem) e inicializa uma nova rodada de "degustação" dos provedores. A classe geom pretendida reconhece os metadados e carrega o geom. +* Isso "anula" os geoms existentes (se houver) e inicializa uma nova rodada de "degustação" dos providers. A classe geom pretendida reconhece os metadados e coloca o geom em funcionamento. (A sequência de eventos acima é dependente da implementação, mas todo o código existente funciona assim, e é suportado pelas bibliotecas.) [[geom-command]] === Estrutura do Comando GEOM -A biblioteca helper [.filename]#geom_CLASSNAME.so# exporta a estrutura `class_commands`, que é uma matriz dos elementos `struct g_command`. Os comandos são uniformes no formato e se parecem com: +A biblioteca auxiliar [.filename]#geom_CLASSNAME.so# exporta a estrutura `class_commands`, que é um array de elementos `struct g_command`. Os comandos têm um formato uniforme e se parecem com: [.programlisting] .... @@ -288,72 +291,72 @@ A biblioteca helper [.filename]#geom_CLASSNAME.so# exporta a estrutura `class_co Verbos comuns são: -* label - para gravar metadados em dispositivos para que eles possam ser reconhecidos em degustações e criados em geoms -* destroy - para destruir metadados, para que as geoms sejam destruídas +* label - para escrever metadados nos dispositivos para que possam ser reconhecidos durante o processo de "tasting" e trazidos à tona em geoms +* destroy - para destruir metadados, fazendo com que os geoms sejam destruídos Opções comuns são: -* `-v` : be verbose -* `-f` : force +* `-v` : ser verboso (mostrar mais informações) +* `-f` : forçar -Muitas ações, como rotular e destruir metadados, podem ser executadas no userland. Para isso, `struct g_command` fornece o campo `gc_func` que pode ser definido para uma função (no mesmo [.filename]#.so#) que será chamada para processar um verbo. Se `gc_func` for NULL, o comando será passado para o módulo do kernel, para a função `.ctlreq` da classe geom. +Muitas ações, como rotular e destruir metadados, podem ser executadas no espaço de usuário. Para isso, `struct g_command` fornece o campo `gc_func`, que pode ser definido como uma função (no mesmo arquivo [.filename]#.so#) que será chamada para processar um verbo. Se `gc_func` for NULL, o comando será passado para o módulo do kernel, para a função `.ctlreq` da classe geom. [[geom-geoms]] === Geoms -Geoms são instâncias de classes GEOM. Eles possuem dados internos (uma estrutura softc) e algumas funções com as quais eles respondem a eventos externos. +Os Geoms são instâncias das classes GEOM. Eles têm dados internos (uma estrutura softc) e algumas funções com as quais eles respondem a eventos externos. As funções de evento são: -* `.acess`: calcula permissões (leitura / escrita / exclusiva) -* `.dumpconf`: retorna informações formatadas em XML sobre o geom -* `.orphan`: chamado quando algum provedor subjacente é desconectado -* `.spoiled`: chamado quando algum provedor subjacente é gravado -* `.start`: lida com I/O +* `.access` : calcula as permissões (leitura/escrita/exclusiva) +* `.dumpconf` : uma função que retorna informações formatadas em XML sobre o geom +* `.orphan` : chamado quando algum provedor subjacente é desconectado +* `.spoiled` : chamado quando algum provedor subjacente é escrito +* `.start` : lida com operações de entrada/saída (I/O) -Estas funções são chamadas a partir da thread `g_down` do kernel e não pode haver sleeping neste contexto, (veja a definição de sleeping em outro lugar) o que limita um pouco o que pode ser feito, mas força o manuseio a ser rápido . +Essas funções são chamadas a partir da thread do kernel `g_down` e não é permitido dormir nesse contexto (consulte a definição de dormir em outro lugar), o que limita bastante o que pode ser feito, mas força o tratamento a ser rápido. -Destes, a função mais importante para fazer o trabalho útil real é a função `.start`(), que é chamada quando uma requisição BIO chega para um provedor gerenciado por uma instância da classe geom. +A função mais importante para realizar trabalho útil é a função `.start()`, que é chamada quando uma solicitação BIO chega para um provider gerenciado por uma instância de classe geom. [[geom-threads]] === Threads GEOM Existem três threads de kernel criados e executados pelo framework GEOM: -* `g_down` : trata de solicitações provenientes de entidades de alto nível (como uma solicitação do userland) no caminho para dispositivos físicos -* `g_up` : lida com respostas de drivers de dispositivos para solicitações feitas por entidades de nível superior -* `g_event` : lida com todos os outros casos: criação de instâncias geom, contagem de acessos, eventos "spoil", etc. +* `g_down` : responsável por lidar com solicitações vindas de entidades de alto nível (como uma solicitação do espaço do usuário) a caminho de dispositivos físicos +* `g_up` : Lida com as respostas dos drivers de dispositivo às solicitações feitas por entidades de nível superior +* `g_event` : lida com todos os outros casos: criação de instâncias de geom, contagem de acesso, eventos de "spoil", etc. -Quando um processo do usuário emite um pedido de "leitura de dados X no deslocamento Y de um arquivo", isto é o que acontece: +Quando um processo do usuário emite uma solicitação para "ler dados X no deslocamento Y de um arquivo", o seguinte acontece: * O sistema de arquivos converte o pedido em uma instância struct bio e o transmite para o subsistema GEOM. Ele sabe o que a instância geom deve manipular porque os sistemas de arquivos são hospedados diretamente em uma instância geom. * A requisição termina como uma chamada para a função `.start`() feita para a thread g_down e atinge a instância geom de nível superior. -* Essa instância geom de nível superior (por exemplo, o segmentador de partições) determina que a solicitação deve ser roteada para uma instância de nível inferior (por exemplo, o driver de disco). Ele faz uma cópia da solicitação bio (solicitações bio _SEMPRE_ precisam ser copiadas entre instâncias, com `g_clone_bio`()!), modifica os campos de dados offset e de provedor de destino e executa a cópia com `g_io_request`() -* O driver de disco obtém a solicitação bio também como uma chamada para `.start`() na thread `g_down`. Ela fala com o hardware, recupera os dados e chama `g_io_deliver`() na bio. -* Agora, a notificação de bio conclusão "borbulha" na thread `g_up`. Primeiro, o slicer de partição obtém `.done`() chamado na thread `g_up`, ele usa as informações armazenadas na bio para liberar a estrutura `bio` clonada (com `g_destroy_bio`()) e chama `g_io_deliver`() no pedido original. +* Esta instância geom de nível superior (por exemplo, o "partition slicer") determina que a solicitação deve ser encaminhada para uma instância de nível inferior (por exemplo, o driver de disco). Ela faz uma cópia da solicitação bio (solicitações bio PRECISAM SEMPRE ser copiadas entre instâncias, com `g_clone_bio`()!), modifica o deslocamento dos dados e os campos do provider de destino e executa a cópia com `g_io_request`() +* O driver de disco também recebe a requisição bio como uma chamada para `.start`() na thread `g_down`. Ele conversa com o hardware, recebe os dados de volta e chama `g_io_deliver`() na bio. +* Agora, a notificação da conclusão do bio "sobe" na thread `g_up`. Primeiro, o particionador recebe `.done`() chamado na thread `g_up`, usa as informações armazenadas no bio para liberar a estrutura de `bio` clonada (com `g_destroy_bio`()) e chama `g_io_deliver`() no pedido original. * O sistema de arquivos obtém os dados e os transfere para o usuário. -Veja a página de manual para o man:g_bio[9] para obter informações sobre como os dados são passados para frente e para trás na estrutura `bio` (observe em particular os campos `bio_parent` e `bio_children` e como eles são manipulados). +Consulte a página do manual man:g_bio[9] para obter informações sobre como os dados são passados de um lado para o outro na estrutura `bio` (observe em particular os campos `bio_parent` e `bio_children` e como eles são manipulados). -Uma característica importante: __NAS THREADS G_UP E G_DOWN NÃO SE PODE DORMIR (SELEEPING)__. Isso significa que nenhuma das seguintes coisas pode ser feita nessas threads (a lista não é completa, mas apenas informativa): +Uma característica importante é que __ NÃO PODEM HAVER CHAMADAS DE FUNÇÃO QUE BLOQUEIEM O PROCESSO (DURMAM) NAS THREADS G_UP E G_DOWN__. Isso significa que nenhuma das seguintes coisas pode ser feita nesses threads (a lista é apenas informativa e não completa): * Chamadas para `msleep`() e `tsleep`(), obviamente. -* Chamadas para `g_write_data`() e `g_read_data`(), porque estes dormem entre passar os dados para os consumidores e retornar. -* Esperando I/O. -* Chamadas para man:malloc[9] e `uma_zalloc`() com o conjunto de flags `M_WAITOK` -* sx e outros sleepable locks +* Chamadas para `g_write_data`() e `g_read_data()`, pois elas dormem entre a passagem dos dados para os consumidores e o retorno. +* Aguardando I/O. +* Chamadas a man:malloc[9] e `uma_zalloc`() com a flag `M_WAITOK` definida +* sx e outros tipos de bloqueios sleepable -Esta restrição está aqui para impedir que o código GEOM obstrua o caminho da solicitação de I/O, já que sleeping normalmente não é limitado pelo tempo e não pode haver garantias sobre quanto tempo levará (também existem algumas outras razões mais técnicas). Isso também significa que não existe muito o que possa ser feito nessas threads; por exemplo, quase qualquer coisa complexa requer alocação de memória. Felizmente, existe uma saída: criar threads adicionais no kernel. +Essa restrição foi imposta para evitar que o código GEOM obstrua o caminho de solicitação de E/S, já que a espera geralmente não está relacionada ao tempo e não há garantias sobre quanto tempo levará (há outras razões técnicas também). Isso também significa que não há muito o que se possa fazer nessas threads; por exemplo, quase qualquer coisa complexa requer alocação de memória. Felizmente, há uma saída: criar threads adicionais do kernel. [[geom-kernelthreads]] === Threads de kernel para uso no código GEOM -As threads do kernel são criadas com a função man:kthread_create[9], e elas são semelhantes aos threads do userland no comportamento, eles somente não podem retornar ao chamador para exprimir a conclusão, mas deve chamar man:kthread_exit[9]. +Threads do Kernel são criados com a função man:kthread_create[9], e eles são parecidos com threads de espaço de usuário em termos de comportamento, apenas que não podem retornar ao chamador para indicar término, mas devem chamar man:kthread_exit[9]. -No código GEOM, o uso usual de threads é para descarregar o processamento de requisições da thread `g_down` (a função `.start`). Estas threads se parecem com um "event handlers": elas têm uma lista encadeada de eventos associados a elas (nos quais eventos podem ser postados por várias funções em várias threads, portanto, devem ser protegidos por um mutex), pegam os eventos da lista, um por um, e processa-os em uma grande instrução `switch`(). +No código do GEOM, o uso usual de threads é para descarregar o processamento de solicitações da thread `g_down` (a função `.start()`). Essas threads se parecem com "manipuladores de eventos": elas têm uma lista vinculada de eventos associados a elas (na qual eventos podem ser postados por várias funções em várias threads, então ela deve ser protegida por um mutex), pegam os eventos da lista um por um e os processam em uma grande declaração `switch()`. -A principal vantagem de usar uma thread para lidar com solicitações de I/O é que ela pode dormir quando necessário. Agora, isso parece bom, mas deve ser cuidadosamente pensado. Dormir é bom e muito conveniente, mas pode ser muito efetivo em destruir o desempenho da transformação geom. As classes extremamente sensíveis ao desempenho provavelmente devem fazer todo o trabalho na chamada de função `.start`(), tomando muito cuidado para lidar com erros de falta de memória e similares. +O principal benefício de usar uma thread para lidar com as solicitações de E/S é que ela pode dormir quando necessário. Agora, isso parece bom, mas deve ser cuidadosamente pensado. Dormir é bem conveniente, mas pode destruir efetivamente o desempenho da transformação geom. As classes extremamente sensíveis ao desempenho provavelmente devem fazer todo o trabalho na chamada de função `.start()`, tendo muito cuidado para lidar com erros de falta de memória e similares. -O outro benefício de ter uma thread de manipulação de eventos como essa é serializar todas as solicitações e respostas provenientes de diferentes threads geom em uma thread. Isso também é muito conveniente, mas pode ser lento. Na maioria dos casos, o tratamento de pedidos `.done`() pode ser deixado para a thread `g_up`. +O outro benefício de ter uma thread de tratamento de eventos é a serialização de todas as solicitações e respostas vindas de diferentes threads do geom em uma única thread. Isso também é muito conveniente, mas pode ser lento. Na maioria dos casos, o tratamento de solicitações `.done`() pode ser deixado para a thread `g_up`. -Mutexes no kernel do FreeBSD (veja man:mutex[9]) têm uma distinção de seus primos mais comuns do userland - o código não pode dormir enquanto estiver segurando um mutex). Se o código precisar dormir muito, os bloqueios man:sx[9] podem ser mais apropriados. Por outro lado, se você faz quase tudo em um único thread, você pode se safar sem utilizar mutexes. +Mutexes no kernel do FreeBSD (veja man:mutex[9]) possuem uma distinção em relação às suas contrapartes mais comuns no userland - o código não pode dormir enquanto segura um mutex. Se o código precisa dormir muito, as travas man:sx[9] podem ser mais apropriadas. Por outro lado, se você fizer quase tudo em um único thread, pode se livrar completamente do uso de mutexes. diff --git a/documentation/content/pt-br/articles/geom-class/_index.po b/documentation/content/pt-br/articles/geom-class/_index.po new file mode 100644 index 0000000000..b1a4793bf7 --- /dev/null +++ b/documentation/content/pt-br/articles/geom-class/_index.po @@ -0,0 +1,1397 @@ +# SOME DESCRIPTIVE TITLE +# Copyright (C) YEAR The FreeBSD Project +# This file is distributed under the same license as the FreeBSD Documentation package. +# Danilo G. Baio , 2021. +# Edson Brandi , 2023. +# "Danilo G. Baio" , 2023. +msgid "" +msgstr "" +"Project-Id-Version: FreeBSD Documentation VERSION\n" +"POT-Creation-Date: 2022-02-01 09:21-0300\n" +"PO-Revision-Date: 2023-05-04 20:00+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" +"Plural-Forms: nplurals=2; plural=n > 1;\n" +"X-Generator: Weblate 4.17\n" + +#. type: YAML Front Matter: description +#: documentation/content/en/articles/geom-class/_index.adoc:1 +#, no-wrap +msgid "A guide to GEOM internals, and writing your own GEOM class" +msgstr "" +"Um guia sobre os internals do GEOM e sobre como escrever sua própria classe " +"GEOM" + +#. type: Title = +#: documentation/content/en/articles/geom-class/_index.adoc:1 +#: documentation/content/en/articles/geom-class/_index.adoc:11 +#, no-wrap +msgid "Writing a GEOM Class" +msgstr "Escrevendo uma classe GEOM" + +#. type: Plain text +#: documentation/content/en/articles/geom-class/_index.adoc:44 +msgid "Abstract" +msgstr "Resumo" + +#. type: Plain text +#: documentation/content/en/articles/geom-class/_index.adoc:47 +msgid "" +"This text documents some starting points in developing GEOM classes, and " +"kernel modules in general. It is assumed that the reader is familiar with C " +"userland programming." +msgstr "" +"Este texto documenta alguns pontos de partida no desenvolvimento de classes " +"GEOM e módulos de kernel em geral. Pressupõe-se que o leitor esteja " +"familiarizado com a programação de espaço de usuário em C." + +#. type: Plain text +#: documentation/content/en/articles/geom-class/_index.adoc:49 +msgid "'''" +msgstr "'''" + +#. type: Title == +#: documentation/content/en/articles/geom-class/_index.adoc:53 +#, no-wrap +msgid "Introduction" +msgstr "Introdução" + +#. type: Title === +#: documentation/content/en/articles/geom-class/_index.adoc:56 +#, no-wrap +msgid "Documentation" +msgstr "Documentação" + +#. type: Plain text +#: documentation/content/en/articles/geom-class/_index.adoc:60 +msgid "" +"Documentation on kernel programming is scarce - it is one of few areas where " +"there is nearly nothing in the way of friendly tutorials, and the phrase " +"\"use the source!\" really holds true. However, there are some bits and " +"pieces (some of them seriously outdated) floating around that should be " +"studied before beginning to code:" +msgstr "" +"A documentação sobre programação de kernel é escassa - é uma das poucas " +"áreas em que quase não há tutoriais amigáveis, e a frase \"use o código " +"fonte!\" realmente é verdadeira. No entanto, existem alguns fragmentos (" +"alguns deles seriamente desatualizados) circulando que devem ser estudados " +"antes de começar a codificar:" + +#. type: Plain text +#: documentation/content/en/articles/geom-class/_index.adoc:62 +msgid "" +"The extref:{developers-handbook}[FreeBSD Developer's Handbook] - part of the " +"documentation project, it does not contain anything specific to kernel " +"programming, but rather some general useful information." +msgstr "" +"O extref:{developers-handbook}[Handbook do Desenvolvedor do FreeBSD] - parte " +"do projeto de documentação, não contém nada específico sobre programação do " +"kernel, mas sim algumas informações úteis em geral." + +#. type: Plain text +#: documentation/content/en/articles/geom-class/_index.adoc:63 +msgid "" +"The extref:{arch-handbook}[FreeBSD Architecture Handbook] - also from the " +"documentation project, contains descriptions of several low-level facilities " +"and procedures. The most important chapter is 13, extref:{arch-handbook}" +"[Writing FreeBSD device drivers, driverbasics]." +msgstr "" +"O extref:{arch-handbook}[Handbook de Arquitetura do FreeBSD] - também do " +"projeto de documentação, contém descrições de várias instalações e " +"procedimentos de baixo nível. O capítulo mais importante é o 13, extref" +":{arch-handbook}[Escrevendo drivers de dispositivos FreeBSD, driverbasics]." + +#. type: Plain text +#: documentation/content/en/articles/geom-class/_index.adoc:64 +msgid "" +"The Blueprints section of http://www.freebsddiary.org[FreeBSD Diary] web " +"site - contains several interesting articles on kernel facilities." +msgstr "" +"A seção Blueprints do site http://www.freebsddiary.org contém vários artigos " +"interessantes sobre as facilidades do kernel." + +#. type: Plain text +#: documentation/content/en/articles/geom-class/_index.adoc:65 +msgid "" +"The man pages in section 9 - for important documentation on kernel functions." +msgstr "" +"As páginas de manual da seção 9 - para documentação importante sobre as " +"funções do kernel." + +#. type: Plain text +#: documentation/content/en/articles/geom-class/_index.adoc:66 +msgid "" +"The man:geom[4] man page and http://phk.freebsd.dk/pubs/[PHK's GEOM slides] " +"- for general introduction of the GEOM subsystem." +msgstr "" +"A página de manual man:geom[4] e os slides sobre o GEOM do PHK em http://phk." +"freebsd.dk/pubs/ - para uma introdução geral ao subsistema GEOM." + +#. type: Plain text +#: documentation/content/en/articles/geom-class/_index.adoc:67 +msgid "" +"Man pages man:g_bio[9], man:g_event[9], man:g_data[9], man:g_geom[9], man:" +"g_provider[9], man:g_consumer[9], man:g_access[9] & others linked from " +"those, for documentation on specific functionalities." +msgstr "" +"As páginas de manual man:g_bio[9], man:g_event[9], man:g_data[9], " +"man:g_geom[9], man:g_provider[9], man:g_consumer[9], man:g_access[9] e " +"outras vinculadas a elas, para documentação sobre funcionalidades " +"específicas." + +#. type: Plain text +#: documentation/content/en/articles/geom-class/_index.adoc:68 +msgid "" +"The man:style[9] man page - for documentation on the coding-style " +"conventions which must be followed for any code which is to be committed to " +"the FreeBSD tree." +msgstr "" +"A página de manual man:style[9] - para documentação sobre as convenções de " +"estilo de codificação que devem ser seguidas para qualquer código que seja " +"commitado para a árvore do FreeBSD." + +#. type: Title == +#: documentation/content/en/articles/geom-class/_index.adoc:70 +#, no-wrap +msgid "Preliminaries" +msgstr "Preliminares" + +#. type: Plain text +#: documentation/content/en/articles/geom-class/_index.adoc:77 +msgid "" +"The best way to do kernel development is to have (at least) two separate " +"computers. One of these would contain the development environment and " +"sources, and the other would be used to test the newly written code by " +"network-booting and network-mounting filesystems from the first one. This " +"way if the new code contains bugs and crashes the machine, it will not mess " +"up the sources (and other \"live\" data). The second system does not even " +"require a proper display. Instead, it could be connected with a serial " +"cable or KVM to the first one." +msgstr "" +"A melhor maneira de desenvolver para o kernel é ter (pelo menos) dois " +"computadores separados. Um deles conteria o ambiente de desenvolvimento e as " +"fontes, e o outro seria usado para testar o código recém-escrito por meio do " +"boot e montagem de sistemas de arquivos por rede do primeiro. Dessa forma, " +"se o novo código contiver erros e travar a máquina, ele não afetará as " +"fontes (e outros dados \"ao vivo\"). O segundo sistema nem mesmo precisa de " +"uma tela adequada. Em vez disso, ele pode ser conectado com um cabo serial " +"ou KVM para o primeiro." + +#. type: Plain text +#: documentation/content/en/articles/geom-class/_index.adoc:80 +msgid "" +"But, since not everybody has two or more computers handy, there are a few " +"things that can be done to prepare an otherwise \"live\" system for " +"developing kernel code. This setup is also applicable for developing in a " +"http://www.vmware.com/[VMWare] or http://www.qemu.org/[QEmu] virtual machine " +"(the next best thing after a dedicated development machine)." +msgstr "" +"No entanto, como nem todo mundo tem dois ou mais computadores disponíveis, " +"existem algumas coisas que podem ser feitas para preparar um sistema \"ao " +"vivo\" para o desenvolvimento de código do kernel. Essa configuração também " +"é aplicável para desenvolvimento em uma máquina virtual http://www.vmware." +"com/[VMWare] ou http://www.qemu.org/[QEmu] (a próxima melhor opção depois de " +"uma máquina de desenvolvimento dedicada)." + +#. type: Title === +#: documentation/content/en/articles/geom-class/_index.adoc:82 +#, no-wrap +msgid "Modifying a System for Development" +msgstr "Modificando um sistema para desenvolvimento" + +#. type: Plain text +#: documentation/content/en/articles/geom-class/_index.adoc:85 +msgid "" +"For any kernel programming a kernel with `INVARIANTS` enabled is a must-" +"have. So enter these in your kernel configuration file:" +msgstr "" +"Para qualquer programação de kernel, é essencial ter um kernel com " +"`INVARIANTS` ativado. Portanto, adicione as seguintes opções no arquivo de " +"configuração do kernel:" + +#. type: delimited block . 4 +#: documentation/content/en/articles/geom-class/_index.adoc:90 +#, no-wrap +msgid "" +"options INVARIANT_SUPPORT\n" +"options INVARIANTS\n" +msgstr "" +"options INVARIANT_SUPPORT\n" +"options INVARIANTS\n" + +#. type: Plain text +#: documentation/content/en/articles/geom-class/_index.adoc:93 +msgid "" +"For more debugging you should also include WITNESS support, which will alert " +"you of mistakes in locking:" +msgstr "" +"Para obter mais depuração, você também deve incluir o suporte a WITNESS, que " +"alertará sobre erros de bloqueio:" + +#. type: delimited block . 4 +#: documentation/content/en/articles/geom-class/_index.adoc:98 +#, no-wrap +msgid "" +"options WITNESS_SUPPORT\n" +"options WITNESS\n" +msgstr "" +"options WITNESS_SUPPORT\n" +"options WITNESS\n" + +#. type: Plain text +#: documentation/content/en/articles/geom-class/_index.adoc:101 +msgid "For debugging crash dumps, a kernel with debug symbols is needed:" +msgstr "" +"Para depurar despejos de falhas (crash dumps), é necessário um kernel com " +"símbolos de depuração:" + +#. type: delimited block . 4 +#: documentation/content/en/articles/geom-class/_index.adoc:105 +#, no-wrap +msgid " makeoptions DEBUG=-g\n" +msgstr " makeoptions DEBUG=-g\n" + +#. type: Plain text +#: documentation/content/en/articles/geom-class/_index.adoc:110 +msgid "" +"With the usual way of installing the kernel (`make installkernel`) the debug " +"kernel will not be automatically installed. It is called [.filename]#kernel." +"debug# and located in [.filename]#/usr/obj/usr/src/sys/KERNELNAME/#. For " +"convenience it should be copied to [.filename]#/boot/kernel/#." +msgstr "" +"Com a maneira usual de instalar o kernel (`make installkernel`), o kernel de " +"depuração não será instalado automaticamente. Ele é chamado de [." +"filename]#kernel.debug# e fica localizado em [.filename]#/usr/obj/usr/src/" +"sys/NOME_DO_KERNEL/#. Por conveniência, ele deve ser copiado para [." +"filename]#/boot/kernel/#." + +#. type: Plain text +#: documentation/content/en/articles/geom-class/_index.adoc:113 +msgid "" +"Another convenience is enabling the kernel debugger so you can examine a " +"kernel panic when it happens. For this, enter the following lines in your " +"kernel configuration file:" +msgstr "" +"Outra conveniência é habilitar o depurador do kernel para que você possa " +"examinar um kernel panic quando ele ocorrer. Para isso, adicione as " +"seguintes linhas no arquivo de configuração do kernel:" + +#. type: delimited block . 4 +#: documentation/content/en/articles/geom-class/_index.adoc:119 +#, no-wrap +msgid "" +"options KDB\n" +"options DDB\n" +"options KDB_TRACE\n" +msgstr "" +"options KDB\n" +"options DDB\n" +"options KDB_TRACE\n" + +#. type: Plain text +#: documentation/content/en/articles/geom-class/_index.adoc:122 +msgid "" +"For this to work you might need to set a sysctl (if it is not on by default):" +msgstr "" +"Para que isso funcione, você pode precisar definir um sysctl (se ele não " +"estiver ativado por padrão):" + +#. type: delimited block . 4 +#: documentation/content/en/articles/geom-class/_index.adoc:126 +#, no-wrap +msgid " debug.debugger_on_panic=1\n" +msgstr " debug.debugger_on_panic=1\n" + +#. type: Plain text +#: documentation/content/en/articles/geom-class/_index.adoc:134 +msgid "" +"Kernel panics will happen, so care should be taken with the filesystem " +"cache. In particular, having softupdates might mean the latest file version " +"could be lost if a panic occurs before it is committed to storage. " +"Disabling softupdates yields a great performance hit, and still does not " +"guarantee data consistency. Mounting filesystem with the \"sync\" option is " +"needed for that. For a compromise, the softupdates cache delays can be " +"shortened. There are three sysctl's that are useful for this (best to be " +"set in [.filename]#/etc/sysctl.conf#):" +msgstr "" +"Panics do kernel podem acontecer, portanto, é preciso ter cuidado com o " +"cache do sistema de arquivos. Em particular, ter softupdates pode significar " +"que a versão mais recente de um arquivo pode ser perdida se ocorrer um panic " +"antes que seja gravada no armazenamento. Desabilitar o softupdates implica " +"em uma grande perda de desempenho e ainda não garante a consistência dos " +"dados. É necessário montar o sistema de arquivos com a opção \"sync\" para " +"garantir isso. Como um compromisso, os atrasos do cache do softupdates podem " +"ser encurtados. Existem três sysctl que são úteis para isso (melhor " +"configurados em [.filename]#/etc/sysctl.conf#):" + +#. type: delimited block . 4 +#: documentation/content/en/articles/geom-class/_index.adoc:140 +#, no-wrap +msgid "" +"kern.filedelay=5\n" +"kern.dirdelay=4\n" +"kern.metadelay=3\n" +msgstr "" +"kern.filedelay=5\n" +"kern.dirdelay=4\n" +"kern.metadelay=3\n" + +#. type: Plain text +#: documentation/content/en/articles/geom-class/_index.adoc:143 +msgid "The numbers represent seconds." +msgstr "Os números representam segundos." + +#. type: Plain text +#: documentation/content/en/articles/geom-class/_index.adoc:151 +msgid "" +"For debugging kernel panics, kernel core dumps are required. Since a kernel " +"panic might make filesystems unusable, this crash dump is first written to a " +"raw partition. Usually, this is the swap partition. This partition must be " +"at least as large as the physical RAM in the machine. On the next boot, the " +"dump is copied to a regular file. This happens after filesystems are " +"checked and mounted, and before swap is enabled. This is controlled with " +"two [.filename]#/etc/rc.conf# variables:" +msgstr "" +"Para depurar panics do kernel, são necessários os despejos de núcleo do " +"kernel. Como um kernel panic pode tornar os sistemas de arquivos " +"inutilizáveis, este despejo de falhas é primeiro gravado em uma partição " +"raw. Geralmente, isso é feito na partição de swap. Esta partição deve ter " +"pelo menos o tamanho da RAM física da máquina. No próximo boot, o despejo é " +"copiado para um arquivo regular. Isso acontece após a verificação e montagem " +"dos sistemas de arquivos e antes que o swap seja ativado. Isso é controlado " +"com duas variáveis do arquivo [.filename]#/etc/rc.conf#:" + +#. type: delimited block . 4 +#: documentation/content/en/articles/geom-class/_index.adoc:156 +#, no-wrap +msgid "" +"dumpdev=\"/dev/ad0s4b\"\n" +"dumpdir=\"/usr/core\n" +msgstr "" +"dumpdev=\"/dev/ad0s4b\"\n" +"dumpdir=\"/usr/core\n" + +#. type: Plain text +#: documentation/content/en/articles/geom-class/_index.adoc:159 +msgid "" +"The `dumpdev` variable specifies the swap partition and `dumpdir` tells the " +"system where in the filesystem to relocate the core dump on reboot." +msgstr "" +"A variável `dumpdev` especifica a partição de swap e `dumpdir` informa ao " +"sistema onde no sistema de arquivos realocar o core dump no reboot." + +#. type: Plain text +#: documentation/content/en/articles/geom-class/_index.adoc:162 +msgid "" +"Writing kernel core dumps is slow and takes a long time so if you have lots " +"of memory (>256M) and lots of panics it could be frustrating to sit and wait " +"while it is done (twice - first to write it to swap, then to relocate it to " +"filesystem). It is convenient then to limit the amount of RAM the system " +"will use via a [.filename]#/boot/loader.conf# tunable:" +msgstr "" +"Gravar o core dump do kernel é lento e leva muito tempo, portanto, se você " +"tiver muita memória (>256 MB) e muitos panics, pode ser frustrante esperar " +"enquanto isso é feito (duas vezes - primeiro para gravá-lo na troca, depois " +"para realocá-lo no sistema de arquivos). É conveniente, portanto, limitar a " +"quantidade de RAM que o sistema usará por meio de um ajuste no [.filename]#/" +"boot/loader.conf#:" + +#. type: delimited block . 4 +#: documentation/content/en/articles/geom-class/_index.adoc:166 +#, no-wrap +msgid " hw.physmem=\"256M\"\n" +msgstr " hw.physmem=\"256M\"\n" + +#. type: Plain text +#: documentation/content/en/articles/geom-class/_index.adoc:169 +msgid "" +"If the panics are frequent and filesystems large (or you simply do not trust " +"softupdates+background fsck) it is advisable to turn background fsck off via " +"[.filename]#/etc/rc.conf# variable:" +msgstr "" +"Se os panics forem frequentes e os sistemas de arquivos forem grandes (ou se " +"você simplesmente não confiar no softupdates + fsck em segundo plano), é " +"aconselhável desativar o fsck em segundo plano por meio da seguinte variável " +"no arquivo [.filename]#/etc/rc.conf#:" + +#. type: delimited block . 4 +#: documentation/content/en/articles/geom-class/_index.adoc:173 +#, no-wrap +msgid " background_fsck=\"NO\"\n" +msgstr " background_fsck=\"NO\"\n" + +#. type: Plain text +#: documentation/content/en/articles/geom-class/_index.adoc:178 +msgid "" +"This way, the filesystems will always get checked when needed. Note that " +"with background fsck, a new panic could happen while it is checking the " +"disks. Again, the safest way is not to have many local filesystems by using " +"another computer as an NFS server." +msgstr "" +"Dessa forma, os sistemas de arquivos serão sempre verificados quando " +"necessário. Observe que, com o fsck em segundo plano, um novo panic pode " +"ocorrer enquanto os discos estão sendo verificados. Novamente, a maneira " +"mais segura é não ter muitos sistemas de arquivos locais, usando outro " +"computador como um servidor NFS." + +#. type: Title === +#: documentation/content/en/articles/geom-class/_index.adoc:180 +#, no-wrap +msgid "Starting the Project" +msgstr "Começando o projeto" + +#. type: Plain text +#: documentation/content/en/articles/geom-class/_index.adoc:184 +msgid "" +"For the purpose of creating a new GEOM class, an empty subdirectory has to " +"be created under an arbitrary user-accessible directory. You do not have to " +"create the module directory under [.filename]#/usr/src#." +msgstr "" +"Para criar uma nova classe GEOM, um subdiretório vazio deve ser criado em um " +"diretório arbitrário acessível pelo usuário. Você não precisa criar o " +"diretório do módulo em [.filename]#/usr/src#." + +#. type: Title === +#: documentation/content/en/articles/geom-class/_index.adoc:186 +#, no-wrap +msgid "The Makefile" +msgstr "O Makefile" + +#. type: Plain text +#: documentation/content/en/articles/geom-class/_index.adoc:189 +msgid "" +"It is good practice to create [.filename]#Makefiles# for every nontrivial " +"coding project, which of course includes kernel modules." +msgstr "" +"É uma boa prática criar arquivos [.filename]#Makefile# para todos os " +"projetos de codificação não triviais, o que inclui, é claro, módulos do " +"kernel." + +#. type: Plain text +#: documentation/content/en/articles/geom-class/_index.adoc:192 +msgid "" +"Creating the [.filename]#Makefile# is simple thanks to an extensive set of " +"helper routines provided by the system. In short, here is how a minimal [." +"filename]#Makefile# looks for a kernel module:" +msgstr "" +"Criar o arquivo [.filename]#Makefile# é simples graças a um extenso conjunto " +"de rotinas auxiliares fornecidas pelo sistema. Em resumo, aqui está como um [" +".filename]#Makefile# mínimo se parece para um módulo do kernel:" + +#. type: delimited block . 4 +#: documentation/content/en/articles/geom-class/_index.adoc:197 +#, no-wrap +msgid "" +"SRCS=g_journal.c\n" +"KMOD=geom_journal\n" +msgstr "" +"SRCS=g_journal.c\n" +"KMOD=geom_journal\n" + +#. type: delimited block . 4 +#: documentation/content/en/articles/geom-class/_index.adoc:199 +#, no-wrap +msgid ".include \n" +msgstr ".include \n" + +#. type: Plain text +#: documentation/content/en/articles/geom-class/_index.adoc:203 +msgid "" +"This [.filename]#Makefile# (with changed filenames) will do for any kernel " +"module, and a GEOM class can reside in just one kernel module. If more than " +"one file is required, list it in the `SRCS` variable, separated with " +"whitespace from other filenames." +msgstr "" +"Este [.filename]#Makefile# (com nomes de arquivo alterados) serve para " +"qualquer módulo do kernel e uma classe GEOM pode residir em apenas um módulo " +"do kernel. Se mais de um arquivo for necessário, liste-os na variável `SRCS`" +", separados por espaço de outros nomes de arquivo." + +#. type: Title == +#: documentation/content/en/articles/geom-class/_index.adoc:205 +#, no-wrap +msgid "On FreeBSD Kernel Programming" +msgstr "Programação do kernel do FreeBSD" + +#. type: Title === +#: documentation/content/en/articles/geom-class/_index.adoc:208 +#, no-wrap +msgid "Memory Allocation" +msgstr "Alocação de memória" + +#. type: Plain text +#: documentation/content/en/articles/geom-class/_index.adoc:213 +msgid "" +"See man:malloc[9]. Basic memory allocation is only slightly different than " +"its userland equivalent. Most notably, `malloc`() and `free`() accept " +"additional parameters as is described in the man page." +msgstr "" +"Consulte man:malloc[9]. A alocação básica de memória é apenas ligeiramente " +"diferente da sua equivalente no espaço do usuário. Mais notavelmente, " +"`malloc()` e `free()` aceitam parâmetros adicionais conforme descrito na " +"página do manual." + +#. type: Plain text +#: documentation/content/en/articles/geom-class/_index.adoc:215 +msgid "" +"A \"malloc type\" must be declared in the declaration section of a source " +"file, like this:" +msgstr "" +"Um \"malloc type\" deve ser declarado na seção de declaração de um arquivo " +"de código fonte, por exemplo desta forma:" + +#. type: delimited block . 4 +#: documentation/content/en/articles/geom-class/_index.adoc:219 +#, no-wrap +msgid " static MALLOC_DEFINE(M_GJOURNAL, \"gjournal data\", \"GEOM_JOURNAL Data\");\n" +msgstr "" +" static MALLOC_DEFINE(M_GJOURNAL, \"gjournal data\", \"GEOM_JOURNAL Data\");" +"\n" + +#. type: Plain text +#: documentation/content/en/articles/geom-class/_index.adoc:222 +msgid "" +"To use this macro, [.filename]#sys/param.h#, [.filename]#sys/kernel.h# and [." +"filename]#sys/malloc.h# headers must be included." +msgstr "" +"Para usar essa macro, os cabeçalhos [.filename]#sys/param.h#, [.filename]#" +"sys/kernel.h# e [.filename]#sys/malloc.h# devem ser incluídos." + +#. type: Plain text +#: documentation/content/en/articles/geom-class/_index.adoc:225 +msgid "" +"There is another mechanism for allocating memory, the UMA (Universal Memory " +"Allocator). See man:uma[9] for details, but it is a special type of " +"allocator mainly used for speedy allocation of lists comprised of same-sized " +"items (for example, dynamic arrays of structs)." +msgstr "" +"Existe outro mecanismo para alocar memória, o UMA (Universal Memory " +"Allocator). Consulte man:uma[9] para obter detalhes, mas é um tipo especial " +"de alocador usado principalmente para alocação rápida de listas compostas " +"por itens do mesmo tamanho (por exemplo, matrizes dinâmicas de estruturas)." + +#. type: Title === +#: documentation/content/en/articles/geom-class/_index.adoc:227 +#, no-wrap *** 817 LINES SKIPPED *** From nobody Thu May 4 20:14:07 2023 X-Original-To: dev-commits-doc-all@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4QC4lg6KTlz49TyM for ; Thu, 4 May 2023 20:14:07 +0000 (UTC) (envelope-from git@FreeBSD.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4QC4lg3SRdz3Hfs; Thu, 4 May 2023 20:14:07 +0000 (UTC) (envelope-from git@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1683231247; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=nlJXQXEHU56QrB0tH4eF4o1QRoH+nBzUw9DrPKYBY7g=; b=pv0V2Crapj9kQEvow49vz8lUydrUyqelgMhGyLkAEgULSqRkcE3L8ZUcZFkPrywOOFt5XP 8JcGggMZzcr7y3J34X+MVhTXcczbGvJAWQ+TDJDtRqDOvP37Xpx058mrBKk3jkO9Vvi4ZD WDxVQWlE6rlWcBwxOigjXIixtiNTolMjClzYYSkzAGu99Yk5ZVFTjk0Vq5K1IlmMiAZMfH VQqd5t8uiM16YSwRn4rQ1vPDD7gvYxNzmZYl5p5u5yqQlskTDFxZB5ldRFn0B02RwcWn4p 4gPBQEwj6W3a59SAests9CqGyDIgnThNI8eI+RqkPegVwmDVJ9gu5z7C+iWO4g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1683231247; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=nlJXQXEHU56QrB0tH4eF4o1QRoH+nBzUw9DrPKYBY7g=; b=ecUWRv49IEQXdq1rejINUE+iEMKMjj1nWuhK3x1es4bmL2RpWbYB+Lhqy8CduLwrjaL27x L9SADVlDvuFDXw6m63qnbHVfdZupMtB9zS9E/i639t3NiIkNiGieeCXedWa65rdcE9aR1n NJQetbVuQ/Lm/3YLVpvDkak3sk4J9EMJe3jTYKjNVgOrusg6QtEiUcm6SFC41lRphY1dEM JqTd3rLfhezNi+qiJ28rAd2v02gO5cvSL4wVUmjTzRxr47Y4V97s3VHBK5dgmPaoHww9P2 KGKNNeTIMKRqB8HN/77WxlStqVYf11NxDUhiDkdJiCzLwYF1GKItlujk7sT6Eg== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1683231247; a=rsa-sha256; cv=none; b=a+/4nBYTtdxKRYDfUtatMdILs6wtNEtH5ll5/4voOEYbXUiZ6UVj9NUUftJOoZVHHGo0BR 7KvTfTWpsE55FNyrBpF5hhiGt8yPDSBBUMshrAKtHB7FQ+kpfzV1VUKoRI97y++RnYVMUu zhPSiXh8L32oiuKyxaIDQ+ToGLDMx3jPHCqfWzp0tPQqWEt7nbkUXQAEf1WAw6t6mxXY2n xi89GZ84Zt2+Se+GFtaKAF8KDlqsplix39JFKkpV0qOxqvJYSMksWAPgy2RdNYCn42lnZv mJJHvJjrmIUIEUzAJmF4lOUDXZX1KBVuf9qOdCeezbBKhEqVEiYMEIXaXTXR6Q== Received: from gitrepo.freebsd.org (gitrepo.freebsd.org [IPv6:2610:1c1:1:6068::e6a:5]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 4QC4lg2WBSzQfK; Thu, 4 May 2023 20:14:07 +0000 (UTC) (envelope-from git@FreeBSD.org) Received: from gitrepo.freebsd.org ([127.0.1.44]) by gitrepo.freebsd.org (8.16.1/8.16.1) with ESMTP id 344KE7WD016375; Thu, 4 May 2023 20:14:07 GMT (envelope-from git@gitrepo.freebsd.org) Received: (from git@localhost) by gitrepo.freebsd.org (8.16.1/8.16.1/Submit) id 344KE74k016374; Thu, 4 May 2023 20:14:07 GMT (envelope-from git) Date: Thu, 4 May 2023 20:14:07 GMT Message-Id: <202305042014.344KE74k016374@gitrepo.freebsd.org> To: doc-committers@FreeBSD.org, dev-commits-doc-all@FreeBSD.org From: Muhammad Moinur Rahman Subject: git: fedfc8434f - main - vale/style: Utilize vales vocabulary engine List-Id: Commit messages for all branches of the doc repository List-Archive: https://lists.freebsd.org/archives/dev-commits-doc-all List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-dev-commits-doc-all@freebsd.org X-BeenThere: dev-commits-doc-all@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Git-Committer: bofh X-Git-Repository: doc X-Git-Refname: refs/heads/main X-Git-Reftype: branch X-Git-Commit: fedfc8434f1c37b51b66fb43614cb3784f4eef13 Auto-Submitted: auto-generated X-ThisMailContainsUnwantedMimeParts: N The branch main has been updated by bofh: URL: https://cgit.FreeBSD.org/doc/commit/?id=fedfc8434f1c37b51b66fb43614cb3784f4eef13 commit fedfc8434f1c37b51b66fb43614cb3784f4eef13 Author: Muhammad Moinur Rahman AuthorDate: 2023-05-04 19:23:45 +0000 Commit: Muhammad Moinur Rahman CommitDate: 2023-05-04 20:13:56 +0000 vale/style: Utilize vales vocabulary engine - Remove spelling-exceptions list - Vale has it's own engine to add custom vocabulary for adding project specific keywords. Add a vocabulary named Terms - Add the file accept.txt which words should be accepted without any errors - Utilize documentation/content/en/books/arch-handbook/mac/_index.adoc as proof of concept to remove all sort of errors/warnings/suggestion. - Remove EOLSpace - Fix Semantic Line Breakings - Add relevant keywords to the new Vocab file accept.txt - Some codewords were not marked with single tick ` so mark those properly that spelling engine do not throw errors Approved by: carlavilla (mentor) Differential Revision: https://reviews.freebsd.org/D39703 --- .vale.ini | 1 + .vale/styles/FreeBSD/spelling-exceptions.txt | 79 - .vale/styles/Vocab/Terms/accept.txt | 32 + .../content/en/books/arch-handbook/mac/_index.adoc | 1570 ++++++++++++-------- 4 files changed, 978 insertions(+), 704 deletions(-) diff --git a/.vale.ini b/.vale.ini index 4364a08aaf..60ce75b98d 100644 --- a/.vale.ini +++ b/.vale.ini @@ -1,5 +1,6 @@ StylesPath = .vale/styles MinAlertLevel = suggestion +Vocab = Terms [asciidoctor] # enable diff --git a/.vale/styles/FreeBSD/spelling-exceptions.txt b/.vale/styles/FreeBSD/spelling-exceptions.txt deleted file mode 100644 index bd3e66f545..0000000000 --- a/.vale/styles/FreeBSD/spelling-exceptions.txt +++ /dev/null @@ -1,79 +0,0 @@ -Accetta -Beranek -Cheriton -[Cc]hroot -DARPA -Englewood -Ethernets -Ewens -Excelan -FIFOs -Filestores -Fortran -Gandi -Gingell -Interlan -Interprocess -Karels -Kbyte -Kernighan -Macklem -Makefile -Microsystems -O'Reilly -Ousterhout -Ritchie -Rosenblum -Rozier -Sebastopol -Tevanian -Winsock -autoconfiguration -basename -chdir -checksubdir -chmod -chown -coroutine -coroutines -datagrams -deallocate -deallocation -descendents -distfile -errno -execve -fchmod -fchown -filestore -filestores -fstat -interprocess -lseek -malloc -mkdir -mknod -mmap -multiuser -noncanonical -nongraphic -pathnames -poudriere -prepended -public_html -[Qq]uarterly -readv -recv -recvfrom -recvmsg -reimplemented -rmdir -rmport -sendmsg -sendto -subhierarchies -subdirectory -unbuffered -untyped -vnode -writev diff --git a/.vale/styles/Vocab/Terms/accept.txt b/.vale/styles/Vocab/Terms/accept.txt new file mode 100644 index 0000000000..7b081da1af --- /dev/null +++ b/.vale/styles/Vocab/Terms/accept.txt @@ -0,0 +1,32 @@ +(?i)bpf +APIs +Biba +DTDs +Redistributions +Safeport +[Dd]atagram +[Dd]evfs +[Mm]map +[Uu]serland +[Vv]node +demultiplexer +dereference +errno +ioctls +lookups +mbuf +multicast +multilabel +multithreaded +mutex +namespace +procfs +pluggable +statfs +syscall +sysctl\'s +tunables +uid +unloadable +vp +wakeup diff --git a/documentation/content/en/books/arch-handbook/mac/_index.adoc b/documentation/content/en/books/arch-handbook/mac/_index.adoc index a1ee13c101..4cc5b3be83 100644 --- a/documentation/content/en/books/arch-handbook/mac/_index.adoc +++ b/documentation/content/en/books/arch-handbook/mac/_index.adoc @@ -1,6 +1,6 @@ --- title: Chapter 6. The TrustedBSD MAC Framework -authors: +authors: - author: Chris Costello email: chris@FreeBSD.org - author: Robert Watson @@ -64,34 +64,46 @@ Redistribution and use in source (SGML DocBook) and 'compiled' forms (SGML, HTML [IMPORTANT] ==== -THIS DOCUMENTATION IS PROVIDED BY THE NETWORKS ASSOCIATES TECHNOLOGY, INC "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 NETWORKS ASSOCIATES TECHNOLOGY, INC 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. +THIS DOCUMENTATION IS PROVIDED BY THE NETWORKS ASSOCIATES TECHNOLOGY, INC "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 NETWORKS ASSOCIATES TECHNOLOGY, INC 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. ==== [[mac-synopsis]] == Synopsis -FreeBSD includes experimental support for several mandatory access control policies, as well as a framework for kernel security extensibility, the TrustedBSD MAC Framework. The MAC Framework is a pluggable access control framework, permitting new security policies to be easily linked into the kernel, loaded at boot, or loaded dynamically at run-time. The framework provides a variety of features to make it easier to implement new security policies, including the ability to easily tag security labels (such as confidentiality information) onto system objects. +FreeBSD includes experimental support for several mandatory access control policies, as well as a framework for kernel security extensibility, the TrustedBSD MAC Framework. +The MAC Framework is a pluggable access control framework, permitting new security policies to be easily linked into the kernel, loaded at boot, or loaded dynamically at run-time. +The framework provides a variety of features to make it easier to implement new security policies, including the ability to easily tag security labels (such as confidentiality information) onto system objects. This chapter introduces the MAC policy framework and provides documentation for a sample MAC policy module. [[mac-introduction]] == Introduction -The TrustedBSD MAC framework provides a mechanism to allow the compile-time or run-time extension of the kernel access control model. New system policies may be implemented as kernel modules and linked to the kernel; if multiple policy modules are present, their results will be composed. The MAC Framework provides a variety of access control infrastructure services to assist policy writers, including support for transient and persistent policy-agnostic object security labels. This support is currently considered experimental. +The TrustedBSD MAC framework provides a mechanism to allow the compile-time or run-time extension of the kernel access control model. +New system policies may be implemented as kernel modules and linked to the kernel; if multiple policy modules are present, their results will be composed. +The MAC Framework provides a variety of access control infrastructure services to assist policy writers, including support for transient and persistent policy-agnostic object security labels. +This support is currently considered experimental. This chapter provides information appropriate for developers of policy modules, as well as potential consumers of MAC-enabled environments, to learn about how the MAC Framework supports access control extension of the kernel. [[mac-background]] == Policy Background -Mandatory Access Control (MAC), refers to a set of access control policies that are mandatorily enforced on users by the operating system. MAC policies may be contrasted with Discretionary Access Control (DAC) protections, by which non-administrative users may (at their discretion) protect objects. In traditional UNIX systems, DAC protections include file permissions and access control lists; MAC protections include process controls preventing inter-user debugging and firewalls. A variety of MAC policies have been formulated by operating system designers and security researches, including the Multi-Level Security (MLS) confidentiality policy, the Biba integrity policy, Role-Based Access Control (RBAC), Domain and Type Enforcement (DTE), and Type Enforcement (TE). Each model bases decisions on a variety of factors, including user identity, role, and security clearance, as well as security labels on objects representing concepts such as data sensitivity and integrity. +Mandatory Access Control (MAC), refers to a set of access control policies that are mandatorily enforced on users by the operating system. +MAC policies may be contrasted with Discretionary Access Control (DAC) protections, by which non-administrative users may (at their discretion) protect objects. +In traditional UNIX systems, DAC protections include file permissions and access control lists; MAC protections include process controls preventing inter-user debugging and firewalls. +A variety of MAC policies have been formulated by operating system designers and security researches, including the Multi-Level Security (MLS) confidentiality policy, the Biba integrity policy, Role-Based Access Control (RBAC), Domain and Type Enforcement (DTE), and Type Enforcement (TE). +Each model bases decisions on a variety of factors, including user identity, role, and security clearance, as well as security labels on objects representing concepts such as data sensitivity and integrity. -The TrustedBSD MAC Framework is capable of supporting policy modules that implement all of these policies, as well as a broad class of system hardening policies, which may use existing security attributes, such as user and group IDs, as well as extended attributes on files, and other system properties. In addition, despite the name, the MAC Framework can also be used to implement purely discretionary policies, as policy modules are given substantial flexibility in how they authorize protections. +The TrustedBSD MAC Framework is capable of supporting policy modules that implement all of these policies, as well as a broad class of system hardening policies, which may use existing security attributes, such as user and group IDs, as well as extended attributes on files, and other system properties. +In addition, despite the name, the MAC Framework can also be used to implement purely discretionary policies, as policy modules are given substantial flexibility in how they authorize protections. [[mac-framework-kernel-arch]] == MAC Framework Kernel Architecture -The TrustedBSD MAC Framework permits kernel modules to extend the operating system security policy, as well as providing infrastructure functionality required by many access control modules. If multiple policies are simultaneously loaded, the MAC Framework will usefully (for some definition of useful) compose the results of the policies. +The TrustedBSD MAC Framework permits kernel modules to extend the operating system security policy, as well as providing infrastructure functionality required by many access control modules. +If multiple policies are simultaneously loaded, the MAC Framework will usefully (for some definition of useful) compose the results of the policies. [[mac-framework-kernel-arch-elements]] === Kernel Elements @@ -116,56 +128,103 @@ The MAC Framework contains a number of kernel elements: The TrustedBSD MAC Framework may be directly managed using sysctl's, loader tunables, and system calls. -In most cases, sysctl's and loader tunables of the same name modify the same parameters, and control behavior such as enforcement of protections relating to various kernel subsystems. In addition, if MAC debugging support is compiled into the kernel, several counters will be maintained tracking label allocation. It is generally advisable that per-subsystem enforcement controls not be used to control policy behavior in production environments, as they broadly impact the operation of all active policies. Instead, per-policy controls should be preferred, as they provide greater granularity and greater operational consistency for policy modules. +In most cases, sysctl's and loader tunables of the same name modify the same parameters, and control behavior such as enforcement of protections relating to various kernel subsystems. +In addition, if MAC debugging support is compiled into the kernel, several counters will be maintained tracking label allocation. +It is generally advisable that per-subsystem enforcement controls not be used to control policy behavior in production environments, as they broadly impact the operation of all active policies. +Instead, per-policy controls should be preferred, as they provide greater granularity and greater operational consistency for policy modules. Loading and unloading of policy modules is performed using the system module management system calls and other system interfaces, including boot loader variables; policy modules will have the opportunity to influence load and unload events, including preventing undesired unloading of the policy. [[mac-framework-kernel-arch-synchronization]] === Policy List Concurrency and Synchronization -As the set of active policies may change at run-time, and the invocation of entry points is non-atomic, synchronization is required to prevent loading or unloading of policies while an entry point invocation is in progress, freezing the set of active policies for the duration. This is accomplished by means of a framework busy count: whenever an entry point is entered, the busy count is incremented; whenever it is exited, the busy count is decremented. While the busy count is elevated, policy list changes are not permitted, and threads attempting to modify the policy list will sleep until the list is not busy. The busy count is protected by a mutex, and a condition variable is used to wake up sleepers waiting on policy list modifications. One side effect of this synchronization model is that recursion into the MAC Framework from within a policy module is permitted, although not generally used. +As the set of active policies may change at run-time, and the invocation of entry points is non-atomic, synchronization is required to prevent loading or unloading of policies while an entry point invocation is in progress, freezing the set of active policies for the duration. +This is accomplished by means of a framework busy count: whenever an entry point is entered, the busy count is incremented; whenever it is exited, the busy count is decremented. +While the busy count is elevated, policy list changes are not permitted, and threads attempting to modify the policy list will sleep until the list is not busy. +The busy count is protected by a mutex, and a condition variable is used to wake up sleepers waiting on policy list modifications. +One side effect of this synchronization model is that recursion into the MAC Framework from within a policy module is permitted, although not generally used. -Various optimizations are used to reduce the overhead of the busy count, including avoiding the full cost of incrementing and decrementing if the list is empty or contains only static entries (policies that are loaded before the system starts, and cannot be unloaded). A compile-time option is also provided which prevents any change in the set of loaded policies at run-time, which eliminates the mutex locking costs associated with supporting dynamically loaded and unloaded policies as synchronization is no longer required. +Various optimizations are used to reduce the overhead of the busy count, including avoiding the full cost of incrementing and decrementing if the list is empty or contains only static entries (policies that are loaded before the system starts, and cannot be unloaded). +A compile-time option is also provided which prevents any change in the set of loaded policies at run-time, which eliminates the mutex locking costs associated with supporting dynamically loaded and unloaded policies as synchronization is no longer required. As the MAC Framework is not permitted to block in some entry points, a normal sleep lock cannot be used; as a result, it is possible for the load or unload attempt to block for a substantial period of time waiting for the framework to become idle. [[mac-framework-kernel-arch-label-synchronization]] === Label Synchronization -As kernel objects of interest may generally be accessed from more than one thread at a time, and simultaneous entry of more than one thread into the MAC Framework is permitted, security attribute storage maintained by the MAC Framework is carefully synchronized. In general, existing kernel synchronization on kernel object data is used to protect MAC Framework security labels on the object: for example, MAC labels on sockets are protected using the existing socket mutex. Likewise, semantics for concurrent access are generally identical to those of the container objects: for credentials, copy-on-write semantics are maintained for label contents as with the remainder of the credential structure. The MAC Framework asserts necessary locks on objects when invoked with an object reference. Policy authors must be aware of these synchronization semantics, as they will sometimes limit the types of accesses permitted on labels: for example, when a read-only reference to a credential is passed to a policy via an entry point, only read operations are permitted on the label state attached to the credential. +As kernel objects of interest may generally be accessed from more than one thread at a time, and simultaneous entry of more than one thread into the MAC Framework is permitted, security attribute storage maintained by the MAC Framework is carefully synchronized. +In general, existing kernel synchronization on kernel object data is used to protect MAC Framework security labels on the object: for example, MAC labels on sockets are protected using the existing socket mutex. +Likewise, semantics for concurrent access are generally identical to those of the container objects: for credentials, copy-on-write semantics are maintained for label contents as with the remainder of the credential structure. +The MAC Framework asserts necessary locks on objects when invoked with an object reference. +Policy authors must be aware of these synchronization semantics, as they will sometimes limit the types of accesses permitted on labels: for example, when a read-only reference to a credential is passed to a policy via an entry point, only read operations are permitted on the label state attached to the credential. [[mac-framework-kernel-arch-policy-synchronization]] === Policy Synchronization and Concurrency -Policy modules must be written to assume that many kernel threads may simultaneously enter one more policy entry points due to the parallel and preemptive nature of the FreeBSD kernel. If the policy module makes use of mutable state, this may require the use of synchronization primitives within the policy to prevent inconsistent views on that state resulting in incorrect operation of the policy. Policies will generally be able to make use of existing FreeBSD synchronization primitives for this purpose, including mutexes, sleep locks, condition variables, and counting semaphores. However, policies should be written to employ these primitives carefully, respecting existing kernel lock orders, and recognizing that some entry points are not permitted to sleep, limiting the use of primitives in those entry points to mutexes and wakeup operations. +Policy modules must be written to assume that many kernel threads may simultaneously enter one more policy entry points due to the parallel and preemptive nature of the FreeBSD kernel. +If the policy module makes use of mutable state, this may require the use of synchronization primitives within the policy to prevent inconsistent views on that state resulting in incorrect operation of the policy. +Policies will generally be able to make use of existing FreeBSD synchronization primitives for this purpose, including mutexes, sleep locks, condition variables, and counting semaphores. +However, policies should be written to employ these primitives carefully, respecting existing kernel lock orders, and recognizing that some entry points are not permitted to sleep, limiting the use of primitives in those entry points to mutexes and wakeup operations. -When policy modules call out to other kernel subsystems, they will generally need to release any in-policy locks in order to avoid violating the kernel lock order or risking lock recursion. This will maintain policy locks as leaf locks in the global lock order, helping to avoid deadlock. +When policy modules call out to other kernel subsystems, they will generally need to release any in-policy locks in order to avoid violating the kernel lock order or risking lock recursion. +This will maintain policy locks as leaf locks in the global lock order, helping to avoid deadlock. [[mac-framework-kernel-arch-registration]] === Policy Registration -The MAC Framework maintains two lists of active policies: a static list, and a dynamic list. The lists differ only with regards to their locking semantics: an elevated reference count is not required to make use of the static list. When kernel modules containing MAC Framework policies are loaded, the policy module will use `SYSINIT` to invoke a registration function; when a policy module is unloaded, `SYSINIT` will likewise invoke a de-registration function. Registration may fail if a policy module is loaded more than once, if insufficient resources are available for the registration (for example, the policy might require labeling and insufficient labeling state might be available), or other policy prerequisites might not be met (some policies may only be loaded prior to boot). Likewise, de-registration may fail if a policy is flagged as not unloadable. +The MAC Framework maintains two lists of active policies: a static list, and a dynamic list. +The lists differ only with regards to their locking semantics: an elevated reference count is not required to make use of the static list. +When kernel modules containing MAC Framework policies are loaded, the policy module will use `SYSINIT` to invoke a registration function; when a policy module is unloaded, `SYSINIT` will likewise invoke a de-registration function. +Registration may fail if a policy module is loaded more than once, if insufficient resources are available for the registration (for example, the policy might require labeling and insufficient labeling state might be available), or other policy prerequisites might not be met (some policies may only be loaded prior to boot). +Likewise, de-registration may fail if a policy is flagged as not unloadable. [[mac-framework-kernel-arch-entrypoints]] === Entry Points -Kernel services interact with the MAC Framework in two ways: they invoke a series of APIs to notify the framework of relevant events, and they provide a policy-agnostic label structure pointer in security-relevant objects. The label pointer is maintained by the MAC Framework via label management entry points, and permits the Framework to offer a labeling service to policy modules through relatively non-invasive changes to the kernel subsystem maintaining the object. For example, label pointers have been added to processes, process credentials, sockets, pipes, vnodes, Mbufs, network interfaces, IP reassembly queues, and a variety of other security-relevant structures. Kernel services also invoke the MAC Framework when they perform important security decisions, permitting policy modules to augment those decisions based on their own criteria (possibly including data stored in security labels). Most of these security critical decisions will be explicit access control checks; however, so me affect more general decision functions such as packet matching for sockets and label transition at program execution. +Kernel services interact with the MAC Framework in two ways: they invoke a series of APIs to notify the framework of relevant events, and they provide a policy-agnostic label structure pointer in security-relevant objects. +The label pointer is maintained by the MAC Framework via label management entry points, and permits the Framework to offer a labeling service to policy modules through relatively non-invasive changes to the kernel subsystem maintaining the object. +For example, label pointers have been added to processes, process credentials, sockets, pipes, vnodes, Mbufs, network interfaces, IP reassembly queues, and a variety of other security-relevant structures. +Kernel services also invoke the MAC Framework when they perform important security decisions, permitting policy modules to augment those decisions based on their own criteria (possibly including data stored in security labels). +Most of these security critical decisions will be explicit access control checks; however, some affect more general decision functions such as packet matching for sockets and label transition at program execution. [[mac-framework-kernel-arch-composition]] === Policy Composition -When more than one policy module is loaded into the kernel at a time, the results of the policy modules will be composed by the framework using a composition operator. This operator is currently hard-coded, and requires that all active policies must approve a request for it to return success. As policies may return a variety of error conditions (success, access denied, object does not exist, ...), a precedence operator selects the resulting error from the set of errors returned by policies. In general, errors indicating that an object does not exist will be preferred to errors indicating that access to an object is denied. While it is not guaranteed that the resulting composition will be useful or secure, we have found that it is for many useful selections of policies. For example, traditional trusted systems often ship with two or more policies using a similar composition. +When more than one policy module is loaded into the kernel at a time, the results of the policy modules will be composed by the framework using a composition operator. +This operator is currently hard-coded, and requires that all active policies must approve a request for it to return success. +As policies may return a variety of error conditions (success, access denied, object does not exist, ...), a precedence operator selects the resulting error from the set of errors returned by policies. +In general, errors indicating that an object does not exist will be preferred to errors indicating that access to an object is denied. +While it is not guaranteed that the resulting composition will be useful or secure, we have found that it is for many useful selections of policies. +For example, traditional trusted systems often ship with two or more policies using a similar composition. [[mac-framework-kernel-arch-labels]] === Labeling Support -As many interesting access control extensions rely on security labels on objects, the MAC Framework provides a set of policy-agnostic label management system calls covering a variety of user-exposed objects. Common label types include partition identifiers, sensitivity labels, integrity labels, compartments, domains, roles, and types. By policy agnostic, we mean that policy modules are able to completely define the semantics of meta-data associated with an object. Policy modules participate in the internalization and externalization of string-based labels provides by user applications, and can expose multiple label elements to applications if desired. - -In-memory labels are stored in slab-allocated `struct label`, which consists of a fixed-length array of unions, each holding a `void *` pointer and a `long`. Policies registering for label storage will be assigned a "slot" identifier, which may be used to dereference the label storage. The semantics of the storage are left entirely up to the policy module: modules are provided with a variety of entry points associated with the kernel object life cycle, including initialization, association/creation, and destruction. Using these interfaces, it is possible to implement reference counting and other storage models. Direct access to the object structure is generally not required by policy modules to retrieve a label, as the MAC Framework generally passes both a pointer to the object and a direct pointer to the object's label into entry points. The primary exception to this rule is the process credential, which must be manually dereferenced to access the credential label. This may change in future revisions of the MAC Framework. - -Initialization entry points frequently include a sleeping disposition flag indicating whether or not an initialization is permitted to sleep; if sleeping is not permitted, a failure may be returned to cancel allocation of the label (and hence object). This may occur, for example, in the network stack during interrupt handling, where sleeping is not permitted, or while the caller holds a mutex. Due to the performance cost of maintaining labels on in-flight network packets (Mbufs), policies must specifically declare a requirement that Mbuf labels be allocated. Dynamically loaded policies making use of labels must be able to handle the case where their init function has not been called on an object, as objects may already exist when the policy is loaded. The MAC Framework guarantees that uninitialized label slots will hold a 0 or NULL value, which policies may use to detect uninitialized values. However, as allocation of Mbuf labels is conditional, policies must also be able to handle a NULL label pointer for Mbufs if they have been loaded dynamically. - -In the case of file system labels, special support is provided for the persistent storage of security labels in extended attributes. Where available, extended attribute transactions are used to permit consistent compound updates of security labels on vnodes--currently this support is present only in the UFS2 file system. Policy authors may choose to implement multilabel file system object labels using one (or more) extended attributes. For efficiency reasons, the vnode label (`v_label`) is a cache of any on-disk label; policies are able to load values into the cache when the vnode is instantiated, and update the cache as needed. As a result, the extended attribute need not be directly accessed with every access control check. +As many interesting access control extensions rely on security labels on objects, the MAC Framework provides a set of policy-agnostic label management system calls covering a variety of user-exposed objects. +Common label types include partition identifiers, sensitivity labels, integrity labels, compartments, domains, roles, and types. +By policy agnostic, we mean that policy modules are able to completely define the semantics of meta-data associated with an object. +Policy modules participate in the internalization and externalization of string-based labels provides by user applications, and can expose multiple label elements to applications if desired. + +In-memory labels are stored in slab-allocated `struct label`, which consists of a fixed-length array of unions, each holding a `void *` pointer and a `long`. +Policies registering for label storage will be assigned a "slot" identifier, which may be used to dereference the label storage. +The semantics of the storage are left entirely up to the policy module: modules are provided with a variety of entry points associated with the kernel object life cycle, including initialization, association/creation, and destruction. +Using these interfaces, it is possible to implement reference counting and other storage models. +Direct access to the object structure is generally not required by policy modules to retrieve a label, as the MAC Framework generally passes both a pointer to the object and a direct pointer to the object's label into entry points. +The primary exception to this rule is the process credential, which must be manually dereferenced to access the credential label. +This may change in future revisions of the MAC Framework. + +Initialization entry points frequently include a sleeping disposition flag indicating whether or not an initialization is permitted to sleep; if sleeping is not permitted, a failure may be returned to cancel allocation of the label (and hence object). +This may occur, for example, in the network stack during interrupt handling, where sleeping is not permitted, or while the caller holds a mutex. +Due to the performance cost of maintaining labels on in-flight network packets (Mbufs), policies must specifically declare a requirement that Mbuf labels be allocated. +Dynamically loaded policies making use of labels must be able to handle the case where their init function has not been called on an object, as objects may already exist when the policy is loaded. +The MAC Framework guarantees that uninitialized label slots will hold a 0 or NULL value, which policies may use to detect uninitialized values. +However, as allocation of Mbuf labels is conditional, policies must also be able to handle a NULL label pointer for Mbufs if they have been loaded dynamically. + +In the case of file system labels, special support is provided for the persistent storage of security labels in extended attributes. +Where available, extended attribute transactions are used to permit consistent compound updates of security labels on vnodes--currently this support is present only in the UFS2 file system. +Policy authors may choose to implement multilabel file system object labels using one (or more) extended attributes. +For efficiency reasons, the vnode label (`v_label`) is a cache of any on-disk label; policies are able to load values into the cache when the vnode is instantiated, and update the cache as needed. +As a result, the extended attribute need not be directly accessed with every access control check. [NOTE] ==== @@ -177,7 +236,11 @@ Currently, if a labeled policy permits dynamic unloading, its state slot cannot The MAC Framework implements a number of system calls: most of these calls support the policy-agnostic label retrieval and manipulation APIs exposed to user applications. -The label management calls accept a label description structure, `struct mac`, which contains a series of MAC label elements. Each element contains a character string name, and character string value. Each policy will be given the chance to claim a particular element name, permitting policies to expose multiple independent elements if desired. Policy modules perform the internalization and externalization between kernel labels and user-provided labels via entry points, permitting a variety of semantics. Label management system calls are generally wrapped by user library functions to perform memory allocation and error handling, simplifying user applications that must manage labels. +The label management calls accept a label description structure, `struct mac`, which contains a series of MAC label elements. +Each element contains a character string name, and character string value. +Each policy will be given the chance to claim a particular element name, permitting policies to expose multiple independent elements if desired. +Policy modules perform the internalization and externalization between kernel labels and user-provided labels via entry points, permitting a variety of semantics. +Label management system calls are generally wrapped by user library functions to perform memory allocation and error handling, simplifying user applications that must manage labels. The following MAC-related system calls are present in the FreeBSD kernel: @@ -191,7 +254,8 @@ The following MAC-related system calls are present in the FreeBSD kernel: * `mac_get_pid()` may be used to request the label of another process by process id. * `mac_get_link()` is identical to `mac_get_file()`, only it will not follow a symbolic link if it is the final entry in the path, so may be used to retrieve the label on a symlink. * `mac_set_link()` is identical to `mac_set_file()`, only it will not follow a symbolic link if it is the final entry in a path, so may be used to manipulate the label on a symlink. -* `mac_execve()` is identical to the `execve()` system call, only it also accepts a requested label to set the process label to when beginning execution of a new program. This change in label on execution is referred to as a "transition". +* `mac_execve()` is identical to the `execve()` system call, only it also accepts a requested label to set the process label to when beginning execution of a new program. +This change in label on execution is referred to as a "transition". * `mac_get_peer()`, actually implemented via a socket option, retrieves the label of a remote peer on a socket, if available. In addition to these system calls, the `SIOCSIGMAC` and `SIOCSIFMAC` network interface ioctls permit the labels on network interfaces to be retrieved and set. @@ -199,7 +263,9 @@ In addition to these system calls, the `SIOCSIGMAC` and `SIOCSIFMAC` network int [[mac-policy-architecture]] == MAC Policy Architecture -Security policies are either linked directly into the kernel, or compiled into loadable kernel modules that may be loaded at boot, or dynamically using the module loading system calls at runtime. Policy modules interact with the system through a set of declared entry points, providing access to a stream of system events and permitting the policy to influence access control decisions. Each policy contains a number of elements: +Security policies are either linked directly into the kernel, or compiled into loadable kernel modules that may be loaded at boot, or dynamically using the module loading system calls at runtime. +Policy modules interact with the system through a set of declared entry points, providing access to a stream of system events and permitting the policy to influence access control decisions. +Each policy contains a number of elements: * Optional configuration parameters for policy. * Centralized implementation of the policy logic and parameters. @@ -229,37 +295,61 @@ static struct mac_policy_ops mac_policy_ops = }; .... -The MAC policy entry point vector, `mac__policy__ops` in this example, associates functions defined in the module with specific entry points. A complete listing of available entry points and their prototypes may be found in the MAC entry point reference section. Of specific interest during module registration are the .mpo_destroy and .mpo_init entry points. .mpo_init will be invoked once a policy is successfully registered with the module framework but prior to any other entry points becoming active. This permits the policy to perform any policy-specific allocation and initialization, such as initialization of any data or locks. .mpo_destroy will be invoked when a policy module is unloaded to permit releasing of any allocated memory and destruction of locks. Currently, these two entry points are invoked with the MAC policy list mutex held to prevent any other entry points from being invoked: this will be changed, but in the mean time, policies should be careful about what kernel pri mitives they invoke so as to avoid lock ordering or sleeping problems. +The MAC policy entry point vector, `mac__policy__ops` in this example, associates functions defined in the module with specific entry points. +A complete listing of available entry points and their prototypes may be found in the MAC entry point reference section. +Of specific interest during module registration are the .mpo_destroy and .mpo_init entry points. +.mpo_init will be invoked once a policy is successfully registered with the module framework but prior to any other entry points becoming active. +This permits the policy to perform any policy-specific allocation and initialization, such as initialization of any data or locks. +.mpo_destroy will be invoked when a policy module is unloaded to permit releasing of any allocated memory and destruction of locks. +Currently, these two entry points are invoked with the MAC policy list mutex held to prevent any other entry points from being invoked: this will be changed, but in the mean time, policies should be careful about what kernel primitives they invoke so as to avoid lock ordering or sleeping problems. -The policy declaration's module name field exists so that the module may be uniquely identified for the purposes of module dependencies. An appropriate string should be selected. The full string name of the policy is displayed to the user via the kernel log during load and unload events, and also exported when providing status information to userland processes. +The policy declaration's module name field exists so that the module may be uniquely identified for the purposes of module dependencies. +An appropriate string should be selected. +The full string name of the policy is displayed to the user via the kernel log during load and unload events, and also exported when providing status information to userland processes. [[mac-policy-flags]] === Policy Flags -The policy declaration flags field permits the module to provide the framework with information about its capabilities at the time the module is loaded. Currently, three flags are defined: +The policy declaration flags field permits the module to provide the framework with information about its capabilities at the time the module is loaded. +Currently, three flags are defined: MPC_LOADTIME_FLAG_UNLOADOK:: -This flag indicates that the policy module may be unloaded. If this flag is not provided, then the policy framework will reject requests to unload the module. This flag might be used by modules that allocate label state and are unable to free that state at runtime. +This flag indicates that the policy module may be unloaded. +If this flag is not provided, then the policy framework will reject requests to unload the module. +This flag might be used by modules that allocate label state and are unable to free that state at runtime. MPC_LOADTIME_FLAG_NOTLATE:: -This flag indicates that the policy module must be loaded and initialized early in the boot process. If the flag is specified, attempts to register the module following boot will be rejected. The flag may be used by policies that require pervasive labeling of all system objects, and cannot handle objects that have not been properly initialized by the policy. +This flag indicates that the policy module must be loaded and initialized early in the boot process. +If the flag is specified, attempts to register the module following boot will be rejected. +The flag may be used by policies that require pervasive labeling of all system objects, and cannot handle objects that have not been properly initialized by the policy. MPC_LOADTIME_FLAG_LABELMBUFS:: -This flag indicates that the policy module requires labeling of Mbufs, and that memory should always be allocated for the storage of Mbuf labels. By default, the MAC Framework will not allocate label storage for Mbufs unless at least one loaded policy has this flag set. This measurably improves network performance when policies do not require Mbuf labeling. A kernel option, `MAC_ALWAYS_LABEL_MBUF`, exists to force the MAC Framework to allocate Mbuf label storage regardless of the setting of this flag, and may be useful in some environments. +This flag indicates that the policy module requires labeling of Mbufs, and that memory should always be allocated for the storage of Mbuf labels. +By default, the MAC Framework will not allocate label storage for Mbufs unless at least one loaded policy has this flag set. +This measurably improves network performance when policies do not require Mbuf labeling. +A kernel option, `MAC_ALWAYS_LABEL_MBUF`, exists to force the MAC Framework to allocate Mbuf label storage regardless of the setting of this flag, and may be useful in some environments. [NOTE] ==== -Policies using the `MPC_LOADTIME_FLAG_LABELMBUFS` without the `MPC_LOADTIME_FLAG_NOTLATE` flag set must be able to correctly handle `NULL` Mbuf label pointers passed into entry points. This is necessary as in-flight Mbufs without label storage may persist after a policy enabling Mbuf labeling has been loaded. If a policy is loaded before the network subsystem is active (i.e., the policy is not being loaded late), then all Mbufs are guaranteed to have label storage. +Policies using the `MPC_LOADTIME_FLAG_LABELMBUFS` without the `MPC_LOADTIME_FLAG_NOTLATE` flag set must be able to correctly handle `NULL` Mbuf label pointers passed into entry points. +This is necessary as in-flight Mbufs without label storage may persist after a policy enabling Mbuf labeling has been loaded. +If a policy is loaded before the network subsystem is active (i.e., the policy is not being loaded late), then all Mbufs are guaranteed to have label storage. ==== [[mac-policy-entry-points]] === Policy Entry Points -Four classes of entry points are offered to policies registered with the framework: entry points associated with the registration and management of policies, entry points denoting initialization, creation, destruction, and other life cycle events for kernel objects, events associated with access control decisions that the policy module may influence, and calls associated with the management of labels on objects. In addition, a `mac_syscall()` entry point is provided so that policies may extend the kernel interface without registering new system calls. +Four classes of entry points are offered to policies registered with the framework: entry points associated with the registration and management of policies, entry points denoting initialization, creation, destruction, and other life cycle events for kernel objects, events associated with access control decisions that the policy module may influence, and calls associated with the management of labels on objects. +In addition, a `mac_syscall()` entry point is provided so that policies may extend the kernel interface without registering new system calls. -Policy module writers should be aware of the kernel locking strategy, as well as what object locks are available during which entry points. Writers should attempt to avoid deadlock scenarios by avoiding grabbing non-leaf locks inside of entry points, and also follow the locking protocol for object access and modification. In particular, writers should be aware that while necessary locks to access objects and their labels are generally held, sufficient locks to modify an object or its label may not be present for all entry points. Locking information for arguments is documented in the MAC framework entry point document. +Policy module writers should be aware of the kernel locking strategy, as well as what object locks are available during which entry points. +Writers should attempt to avoid deadlock scenarios by avoiding grabbing non-leaf locks inside of entry points, and also follow the locking protocol for object access and modification. +In particular, writers should be aware that while necessary locks to access objects and their labels are generally held, sufficient locks to modify an object or its label may not be present for all entry points. +Locking information for arguments is documented in the MAC framework entry point document. -Policy entry points will pass a reference to the object label along with the object itself. This permits labeled policies to be unaware of the internals of the object yet still make decisions based on the label. The exception to this is the process credential, which is assumed to be understood by policies as a first class security object in the kernel. +Policy entry points will pass a reference to the object label along with the object itself. +This permits labeled policies to be unaware of the internals of the object yet still make decisions based on the label. +The exception to this is the process credential, which is assumed to be understood by policies as a first class security object in the kernel. [[mac-entry-point-reference]] == MAC Policy Entry Point Reference @@ -272,7 +362,7 @@ Policy entry points will pass a reference to the object label along with the obj [source,c] ---- -void mpo_init( conf); +void mpo_init( conf); struct mac_policy_conf *conf; ---- @@ -288,14 +378,16 @@ struct mac_policy_conf *conf; | |=== -Policy load event. The policy list mutex is held, so sleep operations cannot be performed, and calls out to other kernel subsystems must be made with caution. If potentially sleeping memory allocations are required during policy initialization, they should be made using a separate module SYSINIT(). +Policy load event. +The policy list mutex is held, so sleep operations cannot be performed, and calls out to other kernel subsystems must be made with caution. +If potentially sleeping memory allocations are required during policy initialization, they should be made using a separate module SYSINIT(). [[mpo-destroy]] ==== `mpo_destroy` [source,c] ---- -void mpo_destroy( conf); +void mpo_destroy( conf); struct mac_policy_conf *conf; ---- @@ -311,16 +403,17 @@ struct mac_policy_conf *conf; | |=== -Policy load event. The policy list mutex is held, so caution should be applied. +Policy load event. +The policy list mutex is held, so caution should be applied. [[mac-mpo-syscall]] ==== `mpo_syscall` [source,c] ---- -int mpo_syscall( td, - call, - arg); +int mpo_syscall( td, + call, + arg); struct thread *td; int call; void *arg; @@ -346,7 +439,10 @@ void *arg; | |=== -This entry point provides a policy-multiplexed system call so that policies may provide additional services to user processes without registering specific system calls. The policy name provided during registration is used to demux calls from userland, and the arguments will be forwarded to this entry point. When implementing new services, security modules should be sure to invoke appropriate access control checks from the MAC framework as needed. For example, if a policy implements an augmented signal functionality, it should call the necessary signal access control checks to invoke the MAC framework and other registered policies. +This entry point provides a policy-multiplexed system call so that policies may provide additional services to user processes without registering specific system calls. +The policy name provided during registration is used to demultiplexer calls from userland, and the arguments will be forwarded to this entry point. +When implementing new services, security modules should be sure to invoke appropriate access control checks from the MAC framework as needed. +For example, if a policy implements an augmented signal functionality, it should call the necessary signal access control checks to invoke the MAC framework and other registered policies. [NOTE] ==== @@ -358,7 +454,7 @@ Modules must currently perform the `copyin()` of the syscall data on their own. [source,c] ---- -void mpo_thread_userret( td); +void mpo_thread_userret( td); struct thread *td; ---- @@ -374,7 +470,11 @@ struct thread *td; | |=== -This entry point permits policy modules to perform MAC-related events when a thread returns to user space, via a system call return, trap return, or otherwise. This is required for policies that have floating process labels, as it is not always possible to acquire the process lock at arbitrary points in the stack during system call processing; process labels might represent traditional authentication data, process history information, or other data. To employ this mechanism, intended changes to the process credential label may be stored in the `p_label` protected by a per-policy spin lock, and then set the per-thread `TDF_ASTPENDING` flag and per-process `PS_MACPENDM` flag to schedule a call to the userret entry point. From this entry point, the policy may create a replacement credential with less concern about the locking context. Policy writers are cautioned that event ordering relating to scheduling an AST and the AST being performed may be complex and interlaced in multithreaded applications. +This entry point permits policy modules to perform MAC-related events when a thread returns to user space, via a system call return, trap return, or otherwise. +This is required for policies that have floating process labels, as it is not always possible to acquire the process lock at arbitrary points in the stack during system call processing; process labels might represent traditional authentication data, process history information, or other data. +To employ this mechanism, intended changes to the process credential label may be stored in the `p_label` protected by a per-policy spin lock, and then set the per-thread `TDF_ASTPENDING` flag and per-process `PS_MACPENDM` flag to schedule a call to the `userret` entry point. +From this entry point, the policy may create a replacement credential with less concern about the locking context. +Policy writers are cautioned that event ordering relating to scheduling an AST and the AST being performed may be complex and interlaced in multithreaded applications. [[mac-label-ops]] === Label Operations @@ -384,7 +484,7 @@ This entry point permits policy modules to perform MAC-related events when a thr [source,c] ---- -void mpo_init_bpfdesc_label( label); +void mpo_init_bpfdesc_label( label); struct label *label; ---- @@ -400,14 +500,15 @@ struct label *label; | |=== -Initialize the label on a newly instantiated bpfdesc (BPF descriptor). Sleeping is permitted. +Initialize the label on a newly instantiated bpfdesc (BPF descriptor). +Sleeping is permitted. [[mac-mpo-init-cred-label]] ==== `mpo_init_cred_label` [source,c] ---- -void mpo_init_cred_label( label); +void mpo_init_cred_label( label); struct label *label; ---- @@ -423,14 +524,15 @@ struct label *label; | |=== -Initialize the label for a newly instantiated user credential. Sleeping is permitted. +Initialize the label for a newly instantiated user credential. +Sleeping is permitted. [[mac-mpo-init-devfsdirent]] ==== `mpo_init_devfsdirent_label` [source,c] ---- -void mpo_init_devfsdirent_label( label); +void mpo_init_devfsdirent_label( label); struct label *label; ---- @@ -446,14 +548,15 @@ struct label *label; | |=== -Initialize the label on a newly instantiated devfs entry. Sleeping is permitted. +Initialize the label on a newly instantiated devfs entry. +Sleeping is permitted. [[mac-mpo-init-ifnet]] ==== `mpo_init_ifnet_label` [source,c] ---- -void mpo_init_ifnet_label( label); +void mpo_init_ifnet_label( label); struct label *label; ---- @@ -469,15 +572,16 @@ struct label *label; | |=== -Initialize the label on a newly instantiated network interface. Sleeping is permitted. +Initialize the label on a newly instantiated network interface. +Sleeping is permitted. [[mac-mpo-init-ipq]] ==== `mpo_init_ipq_label` [source,c] ---- -void mpo_init_ipq_label( label, - flag); +void mpo_init_ipq_label( label, + flag); struct label *label; int flag; ---- @@ -498,15 +602,18 @@ int flag; | |=== -Initialize the label on a newly instantiated IP fragment reassembly queue. The `flag` field may be one of M_WAITOK and M_NOWAIT, and should be employed to avoid performing a sleeping man:malloc[9] during this initialization call. IP fragment reassembly queue allocation frequently occurs in performance sensitive environments, and the implementation should be careful to avoid sleeping or long-lived operations. This entry point is permitted to fail resulting in the failure to allocate the IP fragment reassembly queue. +Initialize the label on a newly instantiated IP fragment reassembly queue. +The `flag` field may be one of M_WAITOK and M_NOWAIT, and should be employed to avoid performing a sleeping man:malloc[9] during this initialization call. +IP fragment reassembly queue allocation frequently occurs in performance sensitive environments, and the implementation should be careful to avoid sleeping or long-lived operations. +This entry point is permitted to fail resulting in the failure to allocate the IP fragment reassembly queue. [[mac-mpo-init-mbuf]] ==== `mpo_init_mbuf_label` [source,c] ---- -void mpo_init_mbuf_label( flag, - label); +void mpo_init_mbuf_label( flag, + label); int flag; struct label *label; ---- @@ -527,15 +634,18 @@ struct label *label; | |=== -Initialize the label on a newly instantiated mbuf packet header (`mbuf`). The `flag` field may be one of M_WAITOK and M_NOWAIT, and should be employed to avoid performing a sleeping man:malloc[9] during this initialization call. Mbuf allocation frequently occurs in performance sensitive environments, and the implementation should be careful to avoid sleeping or long-lived operations. This entry point is permitted to fail resulting in the failure to allocate the mbuf header. +Initialize the label on a newly instantiated mbuf packet header (`mbuf`). +The `flag` field may be one of M_WAITOK and M_NOWAIT, and should be employed to avoid performing a sleeping man:malloc[9] during this initialization call. +Mbuf allocation frequently occurs in performance sensitive environments, and the implementation should be careful to avoid sleeping or long-lived operations. +This entry point is permitted to fail resulting in the failure to allocate the mbuf header. [[mac-mpo-init-mount]] ==== `mpo_init_mount_label` [source,c] ---- -void mpo_init_mount_label( mntlabel, - fslabel); +void mpo_init_mount_label( mntlabel, + fslabel); struct label *mntlabel; struct label *fslabel; ---- @@ -556,14 +666,15 @@ struct label *fslabel; | |=== -Initialize the labels on a newly instantiated mount point. Sleeping is permitted. +Initialize the labels on a newly instantiated mount point. +Sleeping is permitted. [[mac-mpo-init-mount-fs-label]] ==== `mpo_init_mount_fs_label` [source,c] ---- -void mpo_init_mount_fs_label( label); +void mpo_init_mount_fs_label( label); struct label *label; ---- @@ -579,14 +690,15 @@ struct label *label; | |=== -Initialize the label on a newly mounted file system. Sleeping is permitted +Initialize the label on a newly mounted file system. +Sleeping is permitted [[mac-mpo-init-pipe-label]] ==== `mpo_init_pipe_label` [source,c] ---- -void mpo_init_pipe_label( label); +void mpo_init_pipe_label( label); struct label*label; ---- @@ -602,15 +714,16 @@ struct label*label; | |=== -Initialize a label for a newly instantiated pipe. Sleeping is permitted. +Initialize a label for a newly instantiated pipe. +Sleeping is permitted. [[mac-mpo-init-socket]] ==== `mpo_init_socket_label` [source,c] ---- -void mpo_init_socket_label( label, - flag); +void mpo_init_socket_label( label, + flag); struct label *label; int flag; ---- @@ -631,15 +744,16 @@ int flag; | |=== -Initialize a label for a newly instantiated socket. The `flag` field may be one of M_WAITOK and M_NOWAIT, and should be employed to avoid performing a sleeping man:malloc[9] during this initialization call. +Initialize a label for a newly instantiated socket. +The `flag` field may be one of M_WAITOK and M_NOWAIT, and should be employed to avoid performing a sleeping man:malloc[9] during this initialization call. [[mac-mpo-init-socket-peer-label]] ==== `mpo_init_socket_peer_label` [source,c] ---- -void mpo_init_socket_peer_label( label, - flag); +void mpo_init_socket_peer_label( label, + flag); struct label *label; int flag; ---- @@ -660,14 +774,15 @@ int flag; | |=== -Initialize the peer label for a newly instantiated socket. The `flag` field may be one of M_WAITOK and M_NOWAIT, and should be employed to avoid performing a sleeping man:malloc[9] during this initialization call. +Initialize the peer label for a newly instantiated socket. +The `flag` field may be one of M_WAITOK and M_NOWAIT, and should be employed to avoid performing a sleeping man:malloc[9] during this initialization call. [[mac-mpo-init-proc-label]] ==== `mpo_init_proc_label` [source,c] ---- -void mpo_init_proc_label( label); +void mpo_init_proc_label( label); struct label *label; ---- @@ -683,14 +798,15 @@ struct label *label; | |=== -Initialize the label for a newly instantiated process. Sleeping is permitted. +Initialize the label for a newly instantiated process. +Sleeping is permitted. [[mac-mpo-init-vnode]] ==== `mpo_init_vnode_label` [source,c] ---- -void mpo_init_vnode_label( label); +void mpo_init_vnode_label( label); struct label *label; ---- @@ -706,14 +822,15 @@ struct label *label; | |=== -Initialize the label on a newly instantiated vnode. Sleeping is permitted. +Initialize the label on a newly instantiated vnode. +Sleeping is permitted. [[mac-mpo-destroy-bpfdesc]] ==== `mpo_destroy_bpfdesc_label` [source,c] ---- -void mpo_destroy_bpfdesc_label( label); +void mpo_destroy_bpfdesc_label( label); struct label *label; ---- @@ -729,14 +846,15 @@ struct label *label; | |=== -Destroy the label on a BPF descriptor. In this entry point a policy should free any internal storage associated with `label` so that it may be destroyed. +Destroy the label on a BPF descriptor. +In this entry point a policy should free any internal storage associated with `label` so that it may be destroyed. [[mac-mpo-destroy-cred]] ==== `mpo_destroy_cred_label` [source,c] ---- -void mpo_destroy_cred_label( label); +void mpo_destroy_cred_label( label); struct label *label; ---- @@ -752,14 +870,15 @@ struct label *label; | |=== -Destroy the label on a credential. In this entry point, a policy module should free any internal storage associated with `label` so that it may be destroyed. +Destroy the label on a credential. +In this entry point, a policy module should free any internal storage associated with `label` so that it may be destroyed. [[mac-mpo-destroy-devfsdirent]] ==== `mpo_destroy_devfsdirent_label` [source,c] ---- -void mpo_destroy_devfsdirent_label( label); +void mpo_destroy_devfsdirent_label( label); struct label *label; ---- @@ -775,14 +894,15 @@ struct label *label; | |=== -Destroy the label on a devfs entry. In this entry point, a policy module should free any internal storage associated with `label` so that it may be destroyed. +Destroy the label on a devfs entry. +In this entry point, a policy module should free any internal storage associated with `label` so that it may be destroyed. [[mac-mpo-destroy-ifnet-label]] ==== `mpo_destroy_ifnet_label` [source,c] ---- -void mpo_destroy_ifnet_label( label); +void mpo_destroy_ifnet_label( label); struct label *label; ---- @@ -798,14 +918,15 @@ struct label *label; | |=== -Destroy the label on a removed interface. In this entry point, a policy module should free any internal storage associated with `label` so that it may be destroyed. +Destroy the label on a removed interface. +In this entry point, a policy module should free any internal storage associated with `label` so that it may be destroyed. [[mac-mpo-destroy-ipq-label]] ==== `mpo_destroy_ipq_label` [source,c] ---- -void mpo_destroy_ipq_label( label); +void mpo_destroy_ipq_label( label); struct label *label; ---- @@ -821,14 +942,15 @@ struct label *label; | |=== -Destroy the label on an IP fragment queue. In this entry point, a policy module should free any internal storage associated with `label` so that it may be destroyed. +Destroy the label on an IP fragment queue. +In this entry point, a policy module should free any internal storage associated with `label` so that it may be destroyed. [[mac-mpo-destroy-mbuf-label]] ==== `mpo_destroy_mbuf_label` [source,c] ---- -void mpo_destroy_mbuf_label( label); +void mpo_destroy_mbuf_label( label); struct label *label; ---- @@ -844,14 +966,15 @@ struct label *label; | |=== -Destroy the label on an mbuf header. In this entry point, a policy module should free any internal storage associated with `label` so that it may be destroyed. +Destroy the label on an mbuf header. +In this entry point, a policy module should free any internal storage associated with `label` so that it may be destroyed. [[mac-mpo-destroy-mount-label]] ==== `mpo_destroy_mount_label` [source,c] ---- -void mpo_destroy_mount_label( label); +void mpo_destroy_mount_label( label); struct label *label; ---- @@ -867,15 +990,16 @@ struct label *label; | |=== -Destroy the labels on a mount point. In this entry point, a policy module should free the internal storage associated with `mntlabel` so that they may be destroyed. +Destroy the labels on a mount point. +In this entry point, a policy module should free the internal storage associated with `mntlabel` so that they may be destroyed. [[mac-mpo-destroy-mount]] ==== `mpo_destroy_mount_label` [source,c] ---- -void mpo_destroy_mount_label( mntlabel, - fslabel); +void mpo_destroy_mount_label( mntlabel, + fslabel); struct label *mntlabel; struct label *fslabel; ---- @@ -896,14 +1020,15 @@ struct label *fslabel; | |=== -Destroy the labels on a mount point. In this entry point, a policy module should free the internal storage associated with `mntlabel` and `fslabel` so that they may be destroyed. +Destroy the labels on a mount point. +In this entry point, a policy module should free the internal storage associated with `mntlabel` and `fslabel` so that they may be destroyed. [[mac-mpo-destroy-socket]] ==== `mpo_destroy_socket_label` [source,c] ---- -void mpo_destroy_socket_label( label); +void mpo_destroy_socket_label( label); struct label *label; ---- @@ -919,14 +1044,15 @@ struct label *label; | |=== -Destroy the label on a socket. In this entry point, a policy module should free any internal storage associated with `label` so that it may be destroyed. +Destroy the label on a socket. +In this entry point, a policy module should free any internal storage associated with `label` so that it may be destroyed. [[mac-mpo-destroy-socket-peer-label]] ==== `mpo_destroy_socket_peer_label` [source,c] ---- -void mpo_destroy_socket_peer_label( peerlabel); +void mpo_destroy_socket_peer_label( peerlabel); struct label *peerlabel; ---- @@ -942,14 +1068,15 @@ struct label *peerlabel; | |=== -Destroy the peer label on a socket. In this entry point, a policy module should free any internal storage associated with `label` so that it may be destroyed. +Destroy the peer label on a socket. +In this entry point, a policy module should free any internal storage associated with `label` so that it may be destroyed. [[mac-mpo-destroy-pipe-label]] ==== `mpo_destroy_pipe_label` [source,c] ---- -void mpo_destroy_pipe_label( label); +void mpo_destroy_pipe_label( label); struct label *label; ---- @@ -965,14 +1092,15 @@ struct label *label; | |=== -Destroy the label on a pipe. In this entry point, a policy module should free any internal storage associated with `label` so that it may be destroyed. *** 2579 LINES SKIPPED *** From nobody Thu May 4 20:14:08 2023 X-Original-To: dev-commits-doc-all@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4QC4lj10XMz49VDr for ; Thu, 4 May 2023 20:14:09 +0000 (UTC) (envelope-from git@FreeBSD.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4QC4lh4TgDz3HhP; Thu, 4 May 2023 20:14:08 +0000 (UTC) (envelope-from git@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1683231248; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=JvUCPY1T5J7y9FW3ywnHBgFdyMo8kn76dRAfyNc9eMU=; b=L/q6rUtmrCEowwWIdYo1mNn9G2pfiT2+7+uU3myjxLDb/FBmoNoaw604re6f6b3r6Ye+gD DAcaOMRxsPbK6U72LdzzP5Aj2Y5ZHfu9F2wYaMKUDa/x2sCkyMG/qkb6WA/4RNzLoucGYB 2TJSEoq1L3F3dZhBjp7/SAAI4kea1Yr8Zln5rNGaYErRIdcZei96XKzC5nVaxbvlglG5ZU OXn3EDN7989uaQW6doLb3pVtbGSSeRnfZWNztIg5kNiXoURDKx3vdcwfgBmSCQdjxj/bST +oP2Fk+fYNRjEHHWufMcYxqdLvMYopdCY979fW5OWigyctiLpGZv/0AL/Uk1ZA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1683231248; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=JvUCPY1T5J7y9FW3ywnHBgFdyMo8kn76dRAfyNc9eMU=; b=ox6Bi7kWreHixTgnLIShCcsobtvdDbek/N6Ux11vYSbca9r5MhvEtRKO0WA5Svjdzhuqg/ qdDqT9Q+fHpQmqe7kwFcKHRXmGm92Gu0Kl+i9YG6Pmv6CvUanhZZQsVUKl/DuIqVTPRufF YULLccjuEKVQ1UYVlVq/04cJgp+IGrZVPZjTy4xMdxcmFGkeq022YzWjBREozsV4Jvv+eh k/+fOze6oqR/lmUqpG4mKaK9bAytNPOvaXcyFPwQvPxJ4p26Z/rdXFrUO+Qm5L25FEaV0V 8gb/ld+NWepIukN2LOwFRiDp2ubrOFhKsaUcen2u5tYCAT3t8UkDsqAYzd8K9w== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1683231248; a=rsa-sha256; cv=none; b=RhAJi9A+oNHtEyM5mft4Y4QCXqiHLDydpDy/v7WACq6IdsIFYbWweXxL8xEDY3/c/ZtoOM d2j/ptt2vEPCAx3x9VLxLAvl5VsEfzb0qQKlnPxXnDhh3LWsAhozEEf+N+k1f0FBt+FlSW T+rVgZqpWfcTLgwZ6XNt7cDj3UjsDRdPhFJQdkqWPg/tFcDouvj1X66IoqjI/IMT9mekND iJjHfDtkht5QQmlMoPSZOl3TiZpj8Go//z1pEMBM9hYu6JbI/rElkU6Cz0lVS8G0/y7cUd Y+EXdWyfAhyNEAXNejfK4vuOKRTLCMCb4j/nZC14VL0m124nEaigj4joj5A9eg== Received: from gitrepo.freebsd.org (gitrepo.freebsd.org [IPv6:2610:1c1:1:6068::e6a:5]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 4QC4lh3PRlzR9C; Thu, 4 May 2023 20:14:08 +0000 (UTC) (envelope-from git@FreeBSD.org) Received: from gitrepo.freebsd.org ([127.0.1.44]) by gitrepo.freebsd.org (8.16.1/8.16.1) with ESMTP id 344KE8HO016399; Thu, 4 May 2023 20:14:08 GMT (envelope-from git@gitrepo.freebsd.org) Received: (from git@localhost) by gitrepo.freebsd.org (8.16.1/8.16.1/Submit) id 344KE87l016398; Thu, 4 May 2023 20:14:08 GMT (envelope-from git) Date: Thu, 4 May 2023 20:14:08 GMT Message-Id: <202305042014.344KE87l016398@gitrepo.freebsd.org> To: doc-committers@FreeBSD.org, dev-commits-doc-all@FreeBSD.org From: Muhammad Moinur Rahman Subject: git: 1391da325d - main - fdp-primer/writing-style: Refactor after adding new Vale rules List-Id: Commit messages for all branches of the doc repository List-Archive: https://lists.freebsd.org/archives/dev-commits-doc-all List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-dev-commits-doc-all@freebsd.org X-BeenThere: dev-commits-doc-all@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Git-Committer: bofh X-Git-Repository: doc X-Git-Refname: refs/heads/main X-Git-Reftype: branch X-Git-Commit: 1391da325d317b3e5ee9c578da61b61b80de2f95 Auto-Submitted: auto-generated X-ThisMailContainsUnwantedMimeParts: N The branch main has been updated by bofh: URL: https://cgit.FreeBSD.org/doc/commit/?id=1391da325d317b3e5ee9c578da61b61b80de2f95 commit 1391da325d317b3e5ee9c578da61b61b80de2f95 Author: Muhammad Moinur Rahman AuthorDate: 2023-05-04 19:33:01 +0000 Commit: Muhammad Moinur Rahman CommitDate: 2023-05-04 20:13:56 +0000 fdp-primer/writing-style: Refactor after adding new Vale rules Over the last couple of day some new rules has been added, while some rules have been replaced with the one from Vale builtin engines and some have been removed. - Update the fdp-primer to reflect those changes. - As now there are mix of two different styles FreeBSD and Vale be more specific on naming those rules with dotted notation. - Reword the rule FreeBSD.ConsciousLanguage by avoiding sensitive words itself. Approved by: carlavilla (mentor) Differential Revision: https://reviews.freebsd.org/D39800 --- .../en/books/fdp-primer/writing-style/_index.adoc | 76 +++++++++++++--------- 1 file changed, 47 insertions(+), 29 deletions(-) diff --git a/documentation/content/en/books/fdp-primer/writing-style/_index.adoc b/documentation/content/en/books/fdp-primer/writing-style/_index.adoc index a4d3755f5d..8d0161fb81 100644 --- a/documentation/content/en/books/fdp-primer/writing-style/_index.adoc +++ b/documentation/content/en/books/fdp-primer/writing-style/_index.adoc @@ -263,70 +263,88 @@ The following table describes the current rule names and their respective severi | Name | Severity -| BrandTerms +| FreeBSD.BrandTerms | error -| ConsciousLanguage +| FreeBSD.ConsciousLanguage | warning -| Contractions -| suggestions +| FreeBSD.Contractions +| suggestion -| EOLSpacing +| FreeBSD.EOLSpacing | warning -| Hang +| FreeBSD.Hang | warning -| Hyphens +| FreeBSD.Hyphens | warning -| Repetition +| FreeBSD.Spacing +| error + +| FreeBSD.SuperfluousOptArgInLinks +| suggestion + +| FreeBSD.Weasel | warning -| Spacing +| Vale.Avoid | error -| Spelling -| warning +| Vale.Repetition +| error -| Weasel -| warning +| Vale.Spelling +| error + +| Vale.Terms +| error |=== [[writing-style-linting-vale-rules]] === Current Vale Rules -. BrandTerms: According to the copyright rules of The FreeBSD Foundation, *freebsd* should be written as *FreeBSD*. +. FreeBSD.BrandTerms: According to the copyright rules of The FreeBSD Foundation, *freebsd* should be written as *FreeBSD*. Similarly, every major vendor and company has specific rules on writing their brand names and trademarks. -Care should be taken to be respectful to the brand value others and to take time to write PostgreSQL, Node.js, Let's Encrypt etc. +Care should be taken to be respectful to the brand value of others and to take time to write PostgreSQL, Node.js, Let's Encrypt etc. Missing brand names should be added to the [.filename]#.vale/styles/FreeBSD/BrandTerms.yml# in the `doc` repository. -. Contractions: Contracted words should not be used. This rule avoids all contractions and suggests full words. +. FreeBSD.ConsciousLanguage: This rule proposes use of conscious languages so that sensitive words pointing to the color, age, race, sexual orientation of people are avoided where possible. + +. FreeBSD.Contractions: Contracted words should not be used. +This rule avoids all contractions and suggests full words. -. Hang: `Hang` is often used to mean that the application has stopped responding. +. FreeBSD.EOLSpacing: In most of the documents EOL spacing is present which is not the desirable situation. + +. FreeBSD.Hang: `Hang` is often used to mean that the application has stopped responding. This rule proposes better wording. -. Repetition: Some words are often typed twice when leaving the keyboard and rejoining the work again. -This rule finds repeated words and warns the users. +. FreeBSD.Hyphens: Often adverbs ending with 'ly' are added with a hyphen which is wrong. -. Weasel: This rule is aimed at avoiding weasel words. +. FreeBSD.Spacing: Often double spaces are hard to catch with the naked eye and this is addressed here. + +. FreeBSD.SuperfluousOptArgInLinks: Suggest to empty square brackets in `link:` macros when the displayed text coincides with the URL. + +. FreeBSD.Weasel: This rule is aimed at avoiding weasel words. The concept of weasel words is controversial so at the moment the list of words are being evaluated and the severity level is marked as warning only. If a frequently used word is marked as a weasel word it should be removed from [.filename]#.vale/styles/FreeBSD/Weasel.yml# in the `doc` repository. -. ConsciousLanguage: This rule proposes uses of conscious language, for example avoiding the words white/black/master/slave. +. Vale.Avoid: Enforces the *DO NOT USE* vocabulary terms for The FreeBSD Project. +If any word is found that should not be n the documentation the word should be added to the [.filename]#.vale/styles/Vocab/Terms/reject.txt# in the `doc` repository. +The list is empty at the moment. -. EOLSpacing: In most of the documents EOL spacing is present which is not wanted. - -. Hyphens: Often adverbs ending with 'ly' are added with a hyphen which is wrong. +. Vale.Repetition: Same words are often typed twice when leaving the keyboard and rejoining the work again. +This rule finds repeated words and warns the users. -. Spacing: Often double spaces are hard to catch with the naked eye and this is addressed here. +. Vale.Spelling: At the moment there is a mix of en_US and en_UK spellings in the documentation and website. +Vale comes with an in built dictionary from which uses strictly en_US and do not accept the en_UK variant of any words. -. Spelling: At the moment there is a mix of en_US and en_GB spellings in the documentation and website. -A custom dictionary from link:https://wordlist.aspell.net[Aspell] has been added which uses strictly en_US and does not accept the en_GB variant of any words. -It has also an exception list to ignore the FreeBSD specific terms. -At the moment the list is a basic one with minimal words just as a proof of concept but if any word is found to be correct and not available in the dictionary the word should be added to the [.filename]#.vale/styles/FreeBSD/spelling-exceptions.txt# in the `doc` repository. +. Vale.Terms: Enforces the *PREFERRED* vocabulary terms for The FreeBSD Project. +At the moment the list of terms is empty and the FreeBSD specific terms will be added gradually. +If any word is found to be correct and not available in the dictionary the word should be added to the [.filename]#.vale/styles/Vocab/Terms/accept.txt# in the `doc` repository. More rules will be introduced in the upcoming days when and where required. From nobody Fri May 5 17:41:38 2023 X-Original-To: dev-commits-doc-all@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4QCdKH0jxzz49bL6 for ; Fri, 5 May 2023 17:41:39 +0000 (UTC) (envelope-from git@FreeBSD.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4QCdKH0FBWz4L07; Fri, 5 May 2023 17:41:39 +0000 (UTC) (envelope-from git@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1683308499; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=yuEyRk/+xv+A6Wc66yLVskLzD/YxmVrldZXk4hUI8G0=; b=EzOyN/2LEhZweSBhEKl8P/nP44KuaoYU7Q2dp0yn6al2PxDntlpiOC3f7JVaIFIJuqZRjC QsFF6ocKxYU4K+ZdND7kwkEn4UsPleBJAF/Lz1qHTEjGjHJ5Rtd7K1vyUBCah7nqWnHDM1 xSyCZQ69GnEBnuK/YQxz7qbWd5BkQD+CNdsWslKLqgOEuP3vKHghV8o1l5oY+D2S+LXAXJ M07aUfr1QUko6212L7coBf9U0bFai5dfcR+lOsdwcKbsi3j4+AnrrVWqMirVmXsbvI3ER2 zYTAjd7F1YyBMqmQ1NpTAbML2G5u8jE9LdWZPpS0ubyADaKYyjk8tulZeYsi6Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1683308499; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=yuEyRk/+xv+A6Wc66yLVskLzD/YxmVrldZXk4hUI8G0=; b=GlAmsZn98PXJSGl+3dLkqvWC2l6YYgprEwZnUgWaReO+ZtmgUitSY0H8i392CCbHjfO2el U0VJJBinSh3jGCqDEatOYDATYpZoLbTIIsolc8PA5AdDU+nIlQsx1REcRQynzeGKD2Uhkg ecMj0vZh2bacC1z1N1o6CuQJLRueKPLBcEFqQXmYAJqHqe0noSgZX7WD1EzjcryvpI7xHD 4igo2Dy3OT5KTwWgEgK/oWbd6BB2H+dD+qP0zVUYJOQgjyGG/WjUD+68iWUz6G5z+oc9Yb YNo+G5XJ9aI8vvh7T37bAxY4sZOzJyawMjFY+YzpcFeLdKbmM3dprMHfQaNmSQ== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1683308499; a=rsa-sha256; cv=none; b=QZ0a5HKY1znI7xppi/5ZWQHHLn+uARIBigduDo8HnAdla5ZbART7wO3bnZAEiF11drenW2 e4biev4bJzPz7u/v+MdlNnZ9SY61SiYdBKhB2Y0mgk10jW9p3Yr5A8qaoJ6jRZngBMlJ2W lbAzw5JqtJhmpzaqYPARec/rzvHByxlTc1H27t1wLe+sWr62TVLvsRNWf1HNunY5ANZJMd IXp1HqyphWbGcgWY6WYCN0ZPyuh/xfAF8jr8Mv7fSP3PNpk/eCNUBDEk12TaXZenAyv8Vc SmvPpUvGbNPQIAYPaebP7fCkO18JYz4ycm9hBFXDy8hYlkuYMAZwXFkCdpE6Zg== Received: from gitrepo.freebsd.org (gitrepo.freebsd.org [IPv6:2610:1c1:1:6068::e6a:5]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 4QCdKG6PxSz13M9; Fri, 5 May 2023 17:41:38 +0000 (UTC) (envelope-from git@FreeBSD.org) Received: from gitrepo.freebsd.org ([127.0.1.44]) by gitrepo.freebsd.org (8.16.1/8.16.1) with ESMTP id 345Hfcel038252; Fri, 5 May 2023 17:41:38 GMT (envelope-from git@gitrepo.freebsd.org) Received: (from git@localhost) by gitrepo.freebsd.org (8.16.1/8.16.1/Submit) id 345HfcSi038251; Fri, 5 May 2023 17:41:38 GMT (envelope-from git) Date: Fri, 5 May 2023 17:41:38 GMT Message-Id: <202305051741.345HfcSi038251@gitrepo.freebsd.org> To: doc-committers@FreeBSD.org, dev-commits-doc-all@FreeBSD.org From: Graham Perrin Subject: git: 56d55c92b9 - main - handbook/ports: file:// URLs for poudriere repos List-Id: Commit messages for all branches of the doc repository List-Archive: https://lists.freebsd.org/archives/dev-commits-doc-all List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-dev-commits-doc-all@freebsd.org X-BeenThere: dev-commits-doc-all@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Git-Committer: grahamperrin X-Git-Repository: doc X-Git-Refname: refs/heads/main X-Git-Reftype: branch X-Git-Commit: 56d55c92b940c9755f8aba81f9253b93c238a8c1 Auto-Submitted: auto-generated X-ThisMailContainsUnwantedMimeParts: N The branch main has been updated by grahamperrin: URL: https://cgit.FreeBSD.org/doc/commit/?id=56d55c92b940c9755f8aba81f9253b93c238a8c1 commit 56d55c92b940c9755f8aba81f9253b93c238a8c1 Author: Jonathan Vasquez AuthorDate: 2022-05-13 18:00:14 +0000 Commit: Graham Perrin CommitDate: 2023-05-05 17:28:17 +0000 handbook/ports: file:// URLs for poudriere repos FreeBSD Handbook: …: Configuring pkg Clients to Use a Poudriere Repository Add a small section showing the user how to point to their packages repository (package directory in this case) via file://. Allow the user to not publicly expose their packages over the Internet. https://bugs.freebsd.org/263955 PR: 263955 Reported by: Jonathan Vasquez Reviewed by: debdrup, pauamma Pull request: https://github.com/freebsd/freebsd-doc/pull/66 --- documentation/content/en/books/handbook/ports/_index.adoc | 10 ++++++++++ 1 file changed, 10 insertions(+) diff --git a/documentation/content/en/books/handbook/ports/_index.adoc b/documentation/content/en/books/handbook/ports/_index.adoc index 39a6d8173a..4690379e63 100644 --- a/documentation/content/en/books/handbook/ports/_index.adoc +++ b/documentation/content/en/books/handbook/ports/_index.adoc @@ -1285,6 +1285,16 @@ custom: { } .... +If exposing the package repository to the internet is not desired, the `file://` protocol can be used to point to the repository directly: + +[.programlisting] +.... +custom: { + url: "file:///usr/local/poudriere/data/packages/11amd64", + enabled: yes, +} +.... + [[ports-nextsteps]] == Post-Installation Considerations From nobody Sat May 6 00:38:17 2023 X-Original-To: dev-commits-doc-all@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4QCpZ13FRmz4B150 for ; Sat, 6 May 2023 00:38:17 +0000 (UTC) (envelope-from git@FreeBSD.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4QCpZ12nqrz43x5; Sat, 6 May 2023 00:38:17 +0000 (UTC) (envelope-from git@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1683333497; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=/qPjhK2XpVb++4J2W9X5wDd9iW3i9gERvjPi1l3Heno=; b=K+IEcPaRtXEq/ucU+AIGmoSE/g+eX60XNMe1AgvTE+IRQYR9k9feJOwzdzVRWfnSsJIwA0 FCxbheMkcI7WiJY4cCUf5ijwFgdTbDABHgZlvQxewgjLLSf6Ag08eRHFsNtOYpeEr5pxFn s9vfI5tvqMbQ7rCOYlnibEgGH8PqcRFWLARlYctr09GkiuZpGEqn90Gpu9AtAEmMA/7tBV 4g7+R/3vC4fS+2/nqqSbJ59UgnsCc1LOZXKc+SSU5vrK0F49XirGgAi8Exv/Uc0MF0K+qT JZ2Dz1JjWg6khcDo5EXZjvJzaAGSqf+XpEalslEkClc1LuNcI+1sSYh8fxibNA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1683333497; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=/qPjhK2XpVb++4J2W9X5wDd9iW3i9gERvjPi1l3Heno=; b=kxim8q19VMxcqEgxatp6dZpuKIY6FMPvFR4pKK9FteRvTQr67D+CJ/lzOAO/oBIxwTbexf tFTUPaxNnNgUZEhkXU4uzrPhPpjTCICQoe66JOIgqe39E4jEzozigeYCIH3ahUe2qyvr2r /3QzIDKxEOh8NsRLPAowFWI5FNJ3LohY7CaDpGmtU11oiPX5lQd9jq7ymvVTzcBQWE5yge YhdsMptF8JJQcoMr/IZIkTrqOEBQumwrMgnreqdLxkOwV8G/zSkKvJ6o8Gn8ZQu5FlxMJG Cmf+pXjZmldQYFVccTCKM2Euus/DOhJXV/zO1BDSoBTuZO2pGRvxUSW3SRmtFA== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1683333497; a=rsa-sha256; cv=none; b=lD3mtBzVPfMDot1BbCZD63xQ+u1mGDuOo/5nStngRH2JG+NVTgRlWgICuk3Ofm4Ax5JuNm jUQygtJNRNlwWAsu8MPiud9mOIaJQaKK/D0tD3Qlxp99nel3dQyc5SfYdO2OUm8zPtxH0i 71Zc6hufUZy0EKWay94/MPKYKRapkgsvFLmK2+wy5F6QT5qqo3G2eThbd0G+bFQhjh3N07 aEBahs7vTLNV0GKqoMeo4D7V7485fklGHsIf9T+ZWMVB+G8xgDnd68t4wz1Yj4we7IEpcn VvUa1B8wj6e7g9aUFskUpAcT3/9Uhi0Vt2owOxi1zKqvVrbzWOUsc9hp3bhEHg== Received: from gitrepo.freebsd.org (gitrepo.freebsd.org [IPv6:2610:1c1:1:6068::e6a:5]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 4QCpZ11trTzGKJ; Sat, 6 May 2023 00:38:17 +0000 (UTC) (envelope-from git@FreeBSD.org) Received: from gitrepo.freebsd.org ([127.0.1.44]) by gitrepo.freebsd.org (8.16.1/8.16.1) with ESMTP id 3460cHKX020069; Sat, 6 May 2023 00:38:17 GMT (envelope-from git@gitrepo.freebsd.org) Received: (from git@localhost) by gitrepo.freebsd.org (8.16.1/8.16.1/Submit) id 3460cHKQ020068; Sat, 6 May 2023 00:38:17 GMT (envelope-from git) Date: Sat, 6 May 2023 00:38:17 GMT Message-Id: <202305060038.3460cHKQ020068@gitrepo.freebsd.org> To: doc-committers@FreeBSD.org, dev-commits-doc-all@FreeBSD.org From: Charlie Li Subject: git: ba15679884 - main - pgpkeys: replace my key List-Id: Commit messages for all branches of the doc repository List-Archive: https://lists.freebsd.org/archives/dev-commits-doc-all List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-dev-commits-doc-all@freebsd.org X-BeenThere: dev-commits-doc-all@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Git-Committer: vishwin X-Git-Repository: doc X-Git-Refname: refs/heads/main X-Git-Reftype: branch X-Git-Commit: ba1567988437ff28a92785b4dd49aa627841cc33 Auto-Submitted: auto-generated X-ThisMailContainsUnwantedMimeParts: N The branch main has been updated by vishwin: URL: https://cgit.FreeBSD.org/doc/commit/?id=ba1567988437ff28a92785b4dd49aa627841cc33 commit ba1567988437ff28a92785b4dd49aa627841cc33 Author: Charlie Li AuthorDate: 2023-05-06 00:37:15 +0000 Commit: Charlie Li CommitDate: 2023-05-06 00:37:15 +0000 pgpkeys: replace my key Approved by: doc (implicit) --- documentation/static/pgpkeys/vishwin.key | 69 ++++++++------------------------ 1 file changed, 16 insertions(+), 53 deletions(-) diff --git a/documentation/static/pgpkeys/vishwin.key b/documentation/static/pgpkeys/vishwin.key index 663c41dd1a..463061aeed 100644 --- a/documentation/static/pgpkeys/vishwin.key +++ b/documentation/static/pgpkeys/vishwin.key @@ -1,11 +1,12 @@ -// sh addkey.sh vishwin FEB7852BE29B3E87 ; +// sh addkey.sh vishwin 678F936058415CCA ; [.literal-block-margin] .... -pub rsa4096/FEB7852BE29B3E87 2021-05-02 [SC] [expires: 2023-05-16] - Key fingerprint = 2577 79BA D34D 8697 8770 1331 FEB7 852B E29B 3E87 +pub ed25519/678F936058415CCA 2023-05-05 [SC] [expires: 2025-06-06] + Key fingerprint = 5340 0EEF 05FA 3CCB 5CC4 D6BA 678F 9360 5841 5CCA uid Charlie Li (FreeBSD Project) -sub rsa4096/2F452088A7FB535E 2021-05-02 [E] [expires: 2023-05-02] +sub cv25519/89D366E76A3B1761 2023-05-05 [E] [expires: 2025-06-06] + Key fingerprint = 61F4 C068 BA81 8F12 9FD8 D83D 89D3 66E7 6A3B 1761 .... @@ -13,54 +14,16 @@ sub rsa4096/2F452088A7FB535E 2021-05-02 [E] [expires: 2023-05-02] .... -----BEGIN PGP PUBLIC KEY BLOCK----- -mQINBGCOEbUBEACsAJytQ+p1D27T9El6AbDi/PlGlz2X/Sn5ZqAId+JcxcNbdJgc -ZLbCVOTUSfBo+OFytxRCBw867yfZlRdC8aEvubo7pdnho45G+U5lXeWvwwLGUSrU -7LDIaCmFj70iY/aSaYQp2WPALcIpzSXyPeJuuLuiELsCSm3g3eD6wk2ttvobWRzp -DmL9JH/5oaTLRcZatb+9fUXR4rKXodZFAuDkmX8XS5Kcajv35zfOozRfvrDM88K3 -JHRjpwbRNlhHMggNKuoFJ2fkOfwE34H2Pd5Si6kL41Fv5d1oe/p45GxDZp5/Uvo3 -O/4H+v8s7f5HIt2xQu7Jp6AvpShvHcxnSJNIukBbtI2P/28HQOuZPc6bO6cl/qhR -T+J/5GuKs0AECprxz1PgLRZoZbFWTiN11ohdNoZjl6mW5qOkCeZfgd+KP/TkY+Gc -gM95hGWvigPtL5leCZcfGORgarhJ7kbVF4PtIBM9+UhZlgwEOyu6iRQr8GQ8BW23 -09TLDzwVj71pj18EaHAbYD7mS2/62ABCYG+tr1Cbu3UH9CcTNkc1tF2pyMn338bv -OuUWFHhaC2QVTwvOdyaArMhaBvSkTppoJJzvafUadss3e0PnMABZG3uyOzo5MzjY -XpkiCSWTB7OnOu6KE0bQ2d9SVz6IiXzMAbYZob3oMpU/R6Y0AmOWG9oflQARAQAB -tDJDaGFybGllIExpIChGcmVlQlNEIFByb2plY3QpIDx2aXNod2luQEZyZWVCU0Qu -b3JnPokCVAQTAQgAPgIbAwULCQgHAgYVCgkICwIEFgIDAQIeAQIXgBYhBCV3ebrT -TYaXh3ATMf63hSvimz6HBQJgjhNrBQkD1N21AAoJEP63hSvimz6HvqUP/22zMOCs -Z15zOgmkq/BXjxXarY+/7aeZHP5ip21jhcmJOc9wZHcDgFoAaD2XiHBAk3snjQkw -dYP7iYqMRdNN+2JS5cHZm5M3nOjQNgSceoF0rKESo+Cgnj+l4kty+RFYnIvvKndr -KLQkUV/3dJFmLDhKT/rJezj9tZnAFiGbpW6HWhrWykEqI0g3uZWZAJjm18H/EARF -AovRUtPDzkqxb1/KW/C8WOlMuw9BuDV/fPxxN7zBlKijcQqvxSJ6trsoNOmMqQOF -YOdtusVkxGFg02cplN45juzHOj74zhH38HB/k12LMlfktaga/L+80TPvVZnRew4C -cx3s5HVsyY4BD/3mVmq5X183reunDYSZPNk/CAmPYiLPPwZ0FtDt8k33azt8IROb -kj6uGmJJBHuWdRia5s2iRgx1Oypqr2XQQQVrKAP8z23ACiMtxxeONVAEPrVFeMD2 -OjkMoat0jn103lIH/Jv+6YS9Z20WsVOYqAGkbDy1cHMACH29cSn6HyzvFpHluZ/O -tU2QgB+0FHQ3QDBp1v5lC22apUe6D55BtBSbvqJkvt1J2/ZQRXJAkSpTBLZFqP0H -kbfRGhajDt/6WUJws+wxAIIcpelI0We6tnpqzmIhTE2n1pH3Y8ck7/9HSBkByTZY -bz4BICotWydtHn932/xV2BQ6hsR/d2ZIHNxBuQINBGCOEbUBEACZ6lzhj6K8FvC5 -/fDr85klKzDfY2eWhhd/WahES53ehesoKXlMAhScOvMRpKjyoL6VVrn47g0jnfcm -pZPxUVnVeHz+deuPXPfm+2SHbhpJ+L7fCIrV6haFin84THFraNdqYsDDQjf0ER9A -yDSamqd6WOfEhjJodZb483TUh67dHaMlFOcbY+j82PWhzMlkizrxfm3C37C28uym -qeDxA1k74dVrgtdtX9LJOMm6HzHrtqbkDx0Z+HI2rOqSfzY6Zmxtp3nQpyy/M1Nk -01Cv5AWH2D5z83qObEaN6DxxjEVdCaC7sQEH9K9vWoTZCrnXEwzf58u89F3fdZBg -fbSYuFZXV0q/qrtLL8PHd0/W/mhR2f2POn+aJtJjQu53uZZHRR1HGHWemJYACXgW -yL0K0xING+0MrUJhJFSkWIWJSpNoQZGO6FydKLx6f/abE5AVz9gCjor5FuH2K0Qk -sgKGJz8b/W8+i+whyfoLbPdaVaizL5wBoqFf14/ITN1+Svn8j1Rdhclhf6uQmTIl -Jt2vawl2SEl8SupokEYugwVI99ERlb+eZaIDOixvOVByl4Guf7hEPx4YqdPxE2Hc -lC7KApGODPXVKY3LvDAK6WzTVEybpQaZthwoPRNq97cXkaJFqSzKXUDcIqiPPGLM -CqT/2euRspL8hIL9y2oY7EROApUK7wARAQABiQI8BBgBCAAmFiEEJXd5utNNhpeH -cBMx/reFK+KbPocFAmCOEbUCGwwFCQPCZwAACgkQ/reFK+KbPofxaRAAhdM20RDD -TPDjH1nSvXbb33lvsLwzd3WbmcHcIxEQXBtWpn7YUyb/Oe3xBlDfzuLdQDLijsku -zkETUggx0FBRhPUwyzdsflro1wgfH0EqyuegOq2FY+z2RtQOJDGHb8hBd49GwD9H -5wiSgwDJMA2pjDSr8aG77VDaN1/NeHpE4bmlJGwbKihM0fOoAh8KjZhapJM9ycjk -o61yFrofObO5h+b9WPdpFNyt9eHCGBO6zxpMlEViQ7Fm6t71R7FWP3AIsK6tHAal -zf3IQsbB8r//RYeko8nJa24rl3JdB8MhgDUgx5g5hqRaLSAVmwlH8NdIB2eHXaU+ -iwlA/Y03zgp1yiI4fYz+Vp0By5Sv0k3T9zEzhYaW+ahOq8LqOW4dR5G3x3Ht5F6j -kySF6lBtLwChWGCUbiJYuIzX9ErKzMrwkaBBiA9M66UqVEo7gA2rUIilCgt+V4rn -P8LXjlcF4RK8zmajdzZRixA7iILTNP7m688ZiFnfkeAfOUipMyYjnj4k4M4FGgSt -2a5Dih3g/6Rf8kRMPD1VvdsbOH09FKKi+cnI5aeJ51DpTyT/d2cu9vqy4RfRetDz -xH0jUxEEWOmhG59YBuRH3AgWxJ93UGKconihyQ1G+2quP2tewZQEPMOh5HzKmLpD -7ChTGV5tKqPdWMTfdWjLks8d7C4782boDbQ= -=UfX2 +mDMEZFWWqBYJKwYBBAHaRw8BAQdAINFDmM+bgGkT1C4nD5a3BxgcH8Xnx5qTJbPu +IBxD57K0MkNoYXJsaWUgTGkgKEZyZWVCU0QgUHJvamVjdCkgPHZpc2h3aW5ARnJl +ZUJTRC5vcmc+iJkEExYKAEEWIQRTQA7vBfo8y1zE1rpnj5NgWEFcygUCZFWWqAIb +AwUJA+3ogAULCQgHAgIiAgYVCgkICwIEFgIDAQIeBwIXgAAKCRBnj5NgWEFcylla +AP9CGICFEvTUOv5BYh/H8m49VJ87a/wd0obeQfVBnS464AD9FopTHbjEs0HDV0ZY +mJPxzJIznjumsj9gBxX0bBqqTgy4OARkVZaoEgorBgEEAZdVAQUBAQdA6BUWuG5R +uT0vmtoDyCUUqiJGdtd78GM5ic3kw2AntSADAQgHiH4EGBYKACYWIQRTQA7vBfo8 +y1zE1rpnj5NgWEFcygUCZFWWqAIbDAUJA+3ogAAKCRBnj5NgWEFcyn55AP9ezKDC +UgHqAq6JX976abb9pYdbSjxxNJqnrjgNkfhgIQD/QhR+fgnUHhcGTMBy+pYHZUGH +5DCuITsK1U4+v252uws= +=cNYY -----END PGP PUBLIC KEY BLOCK----- ....