Capítulo 16 Perguntas Variadas

Só parece que o FreeBSD usa mais swap do que o Linux. Na verdade não usa. A principal diferença entre o FreeBSD e o Linux nesse quesito é que o FreeBSD vai sempre remanejar - de forma pró-ativa - toda memória que estiver completamente inativa e subutilizada, para o swap, dessa forma garantindo sempre mais memória principal disponível para utilização. O Linux tende a remanejar páginas de memória para o swap apenas como última alternativa. A utilização mais acentuada do swap é balanceada pela utilização mais eficiente da memória principal.

Note que, pelo fato do FreeBSD ser próativo nesse quesito, ele não decide arbitrariamente fazer swap das páginas quando o sistema está de fato inativo. Portanto você não corre o risco de encontrar todo seu sistema despaginado pela manhã, depois de uma noite inteira de inatividade.

A resposta simples é que memória principal livre é memória desperdiçada. Toda memória que não estiver ativamente alocada pelos seus programas são utilizadas pelo Kernel do FreeBSD como cache de disco. Os valores que o top(1) mostra como Inact, Cache, e Buf são dados referentes ao cache de disco, em estágios distintos de utilização. Esses dados cacheados garantem que o sistema não tenha que fazer acesso em um disco local (muito mais lento que a memória) para utilizar os dados que foram acessados recentemente, garantindo assim melhora significativa na performance geral. Na maioria dos casos, se o top(1) mostrar que existe pouca memória disponível, isso é uma boa indicação, a não ser que seja uma quantidade extremamente baixa.

Para entender porque o FreeBSD usa o formato ELF, você deve primeiro saber um pouco sobre os 3 formatos de executáveis Unix “dominantes” atualmente:

• a.out(5)

  O mais antigo e “classico”formato de objetos Unix. Ele usa um cabeçalho curto e compacto, com um “magic number” no início que é frequentemente utilizado para identificar seu formato (mais detalhes veja a.out(5)). Ele contém três segmentos a serem carregados: .text, .data, e .bss acrescidos de uma tabela de símbolos e uma tabela de caractereres adicionais.

• COFF

  O formato de objetos SVR3. Seu cabeçalho se consiste agora em uma tabela de seções, dessa forma garantindo que você tenha outras seções além de .text, .data, e .bss.

• ELF

  O sucessor do COFF, atribuído de Múltiplas seções e valores de 32-bit ou 64-bit. Um de seus principais inconvenientes: O formato ELF foi originalmente desenvolvido presumindo-se que existiria apenas um único ABI por arquitetura. A presunção é incorreta, e nem mesmo em relação ao mundo comercial do SYSV (onde encontramos ao menos três ABIs distintas: SVR4, Solaris, SCO) isso acontece.

  O FreeBSD tenta se virar com esse problema com um utilitário que identifica um executável ELF relacionando-o ao ABI com o qual ele é compatível. Veja a página de manual do brandelf(1) para maiores informações.

O FreeBSD vem de tradição “clássica” e por isso sempre usou o formado a.out(5) que é uma tecnologia que foi experimentada e aprovada por várias gerações de sistemas BSD. Apesar de, há algum tempo também ser possível para o FreeBSD trabalhar nativamente com binários ELF (e também kernels), o FreeBSD inicialmente resistiu à “pressão” em assumir o ELF como formato padrão. Por quê? Bem, quando o campo do Linux resolveu fazer sua dolorosa transição para o formato ELF, não sobrou muito para ser aproveitado dos formatos a.out especialmente por causa das limitações de tabelas que podiam ser utilizadas em seus cabeçalhos, e isso tornou o desenvolvimento de bibliotecas compartilhadas extremamente árduo para fabricantes e desenvolvedores em geral. Depois disso, as ferramentas ELF começaram à oferecer soluções para o compartilhamento de bibliotecas, soluções que fossem extremamente satisfatórias, e a migração, apesar dos custos necessários que a envolvia, foi aceita, e a transição para ELF passou a ser o “caminho à ser seguido”.

No caso do FreeBSD, o nosso mecanismo de bibliotecas compartilhadas tem uma base mais próxima do estilo do SunOS, da Sun, e é extremamente fácil de ser utilizado. Contudo, à partir da série 3.0, o FreeBSD oficialmente adotou o formato de binários ELF como padrão. Apesar do formato a.out sempre ter servido muito bem às nossas necessidades, o pessoal da GNU, autores de algumas das ferramentas de compilação que nós usamos, simplesmente deixaram de suportar o formato a.out. Tal fato nos forçou à manter versões distintas do compilador e do linkador, e nos permitiriam usufruir dos esforços que nós achássemos interessantes nos desenvolvimentos GNU. Finalmente, a demanda pelo ISO-C++, notáveis compiladores e descompiladores, também contribuiram para uma adoção nativa dos binários ELF nas versões futuras do FreeBSD.

De volta às origens, em um passado obscuro, existiam apenas hardwares mais simples. Esse hardware simples, suportava sistemas simples e pequenos. A a.out era completamente adequada para o serviço de representar o formato binário nesses sistemas (os PDP-11). Conforme as pessoas iam portando o Unix desse sistema mais simples, eles mantinham o formato a.out porque era bom o bastante para portar para arquiteturas como o Motorola 68k, VAXen, etc.

Então, algum engenheiro de hardware brilhante, decidiu que se ele pudesse forçar o software à dar conta de algumas coisinhas, alguns truquezinhos, ele poderia então passar por cima de algumas restrições de design, e permitir que a base de sua CPU tivesse um desempenho melhor. Para poder trabalhar como esse novo tipo de hardware (que hoje é conhecido como RISC), a a.out não se encaixava muito bem em suas funções, e então muitos formatos foram desenvolvidos afim de obter melhor performance desse hardware, que a simples a.out não podia comportar. Coisas como COFF, ECOFF e outras ainda mais obscuras foram inventadas, e todas suas limitações foram exploradas, até que se resultasse o formato ELF.

Em adição, o tamanho dos programas passou a crescer, e os discos (assim como a memória física) ainda eram relativamente pequenos, então nasceu o conceito de compartilhamento de bibliotecas. O sistema de Memória Virtual (VM) também se tornou mais sofisticado. Cada um desses avanços eram feitos utilizando-se o formato a.out, e o seu uso crescia mais e mais com cada nova característica. Depois, as pessoas começaram a querer que as coisas fossem dinâmicamente carregadas em tempo de execussão, ou então queriam poder descartar algum trecho de seus programas depois que seu código de inicialização tivesse sido executado, de modo à economizar memória principal ou mesmo Swap. As linguagens de programação se tornaram mais sofisticadas, então as pessoas queriam códigos com chamadas automáticas antes do programa principal (main). Começou-se então a hackear a a.out de forma que ela pudesse suprir essas necessidades. E de fato por algum tempo ela as supriu. Depois a a.out passou a não suportar mais determinados problemas sem resultar em uma sobrecarga ou complexidade exagerada de código. Por outro lado, o formato ELF resolvia a maioria desses problemas, mas seria doloroso demais simplesmente abandonar um formato e sistema que, basicamente funcionavam bem. Então o formato ELF teve que esperar até que fosse ainda mais doloroso continuar com o formato a.out do que migrar para ELF.

Contudo, com o passar do tempo, as ferramentas de desenvolvimento às quais o FreeBSD derivava suas próprias ferramentas de desenvolvimento (especialmente o assembler e o carregador - loader) se envolveram em duas árvores paralelas. A árvore do FreeBSD adicionou inúmeras bibliotecas compartilhadas, e arrumou inúmeros bugs. E a rapaziada do GNU, que originalmente escreviam algumas dessas ferramentas, passaram a rescreve-las e adicionaram suporte para compilação derivada, adoções de formatos diferentes, etc. Depois pensou-se em desenvolver um formato derivado, visando o FreeBSD, mas não obteve-se sorte o bastante, especialmente porque os fontes antigos do "ld" do FreeBSD não davam conta da tarefa. A corrente de novas ferramentas GNU (as chamadas binutils) agora suportam compilação derivada, formato ELF, bibliotecas compartilhadas, extensões de C++, etc, etc. Em adição ainda, muitos fabricantes passaram à lançar binários ELF, e então, por que continuar nos chateando com o formato a.out? A a.out é um cavalo velho e muito cansado, que já provou ser extremamente útil no passado, mas agora está na hora de tira-lo do pasto, como recompensa por seus longos e fiéis anos de serviço.

O formato ELF é mais expressivo do que o a.out, e vai permitir muito mais extensibilidade à base do sistema. As ferramentas ELF são mantidas de forma mais confiável, e oferecem suporte à compilação derivada, o que é importante para muita gente. O formato ELF é um pouco mais lento do que o formato a.out, mas é quase impossível comparar ambos, existem inúmeros detalhes que os fazem diferentes, desde o mapeamento de páginas de memória, até a forma como eles tratam o código de inicialização de um binário (init code). Nenhuma dessas questões é importante, mas existem diferenças. Com o tempo, o suporte para o formato a.out vai ser retirado do kernel GENERIC, e eventualmente será retirado em definitivo do kernel, uma vez que a necessidade de rodar programas a.out tenham se tornado passado.

Links simbólicos não tem permissões, e por padrão, o chmod(1) não vai seguir os links afim de mudar as permissões do arquivo original. Portanto, se você tem um arquivo qualquer, e um link simbólico para esse arquivo, o seguinte comando vai lhe servir.

% chmod g-w <link simbólico>

Contudo, as permissões para o arquivo original não serão alteradas. Mas se você usar a opção -H ou -L em conjunto com -R, você vai poder alterá-la. Veja as páginas de manuais do chmod(1) e do symlink(7) para mais informações.

Você pode pensar que seria bem confortável simplesmente mudar o UT_NAMESIZE e depois recompilar todo o sistema operacional, ai tudo iria funcionar maravilhosamente bem. Infelizmente não é assim que as coisas funcionam, existem estruturas de aplicações e utilitários (incluindo ferramentas do sistema) que foram codificadas utilizando números pequenos (nem sempre 8 ou 9, mas alguns valores mais arbitrários como 15 e 20) em estruturas e buffers. Você não vai ter problemas apenas com arquivos de logs, que serão inutilizados (devido ao tamanho variável dos dados gravados, quando apenas um tamanho constante era esperado), mas vai também ter problemas com clientes NIS de máquinas Sun, e potencialmente provocar outros problemas ao interagir com outros sistemas Unix.

No FreeBSD 3.0 e posteriores, o tamanho máximo do nome de usuário foi elevado para 16 caracteres, e todas as ferramentas e trechos do código principal do sistema que poderiam apresentar problemas em relação à isso, foram encontradas e corrigidas. O fato dessa alteração mudar tantos fatores importantes no sistema é que, nenhuma mudança tinha sido feita até a versão 3.0.

Se você confia completamente em suas habilitades para procurar e corrigir esses prováveis problemas sozinho, então basta aumentar o tamanho do nome de usuário no arquivo /usr/include/utmp.h e mudar a UT_NAMESIZE para o valor desejado. Você também vai ter que atualizar o MAXLOGNAME no /usr/include/sys/param.h para ficar de acordo com a mudança no UT_NAMESIZE. Finalmente, se você vai recompilar os fontes, não se esqueça que o /usr/include é atualizado sempre. Mude então os arquivos apropriados em /usr/src(...) para garantir que você vai estar alterando sempre a fonte do problema, e não apenas a instância instalada, no sistema.

Sim, à partir da versão 3.0, você pode utilizar o emulador doscmd da BSDI. A emulação DOS desse aplicativo foi totalmente redefinida depois da sua integração do FreeBSD. Entre na lista de discussão sobre a emulação de outros sistemas operacionais no FreeBSD se você tem interesse em se juntar ao grupo que se esforça nessa jornada.

Em sistemas anteriores ao 3.0, existe um utilitário não muito interessante, chamado pcemu no Ports. O pcemu emula um 8088 e algumas função de BIOS que são o bastante para rodar aplicações DOS que sejam textuais. Ele requer o X, sistema de interface grafica (XFree86).

Veja o FAQ de Tradução no FreeBSD Documentation Project Primer.

O sistema de correio eletrônico do site FreeBSD.org implementa algumas das restrições do Postfix, verificando nas mensagens que estão chegando, se elas estão sendo entregues por algum servidor mal configurado, ou se representa algum tipo de SPAM em potencial. As suas mensagens podem estar voltando por algum dos seguintes motivos:

• A mensagem está sendo enviada de um domínio ou bloco de endereços IP reconhecidamente utilizados para SPAM.

  Os servidores de correio eletrônico do projeto FreeBSD rejeitam mensagens de qualquer fonte de SPAM conhecida. Se você utiliza os serviços de uma empresa que costuma fazer SPAM ou permitir que seus clientes o façam, por gentileza, mude o seu provedor de serviços, para um que não permite tal prática.

• O corpo da mensagem contém apenas HTML.

  Mensagens de correio eletrônico devem ser enviadas apenas como texto puro. Mensagens de e-mail não são web sites. Configure o seu cliente de correio eletrônico de modo que ele apenas envie mensagens de texto puro.

• Os servidores da FreeBSD.org não conseguem resolver o seu endereço IP para o nome da estação que está entregando a mensagem eletrônica.

  Por padrão, ter registros de DNS reverso é um dos requisitos para que nossos servidores recebam sua mensagem. Configure o DNS reverso para o IP do seu servidor de e-mail. Lembre-se que, alguns serviços residênciais (como ADSL, dialup, cable, etc) não permitem que você mesmo configure o seu reverso. Nesse caso, envie sua mensagem pelo servidor de e-mail do seu provedor de serviços, ou peça ao provedor que ajuste o reverso do seu IP.

• O nome da estação enviada no cabeçalho inicial EHLO/HELO, parte do protocolo de envio SMTP não pode ser resolvido em um endereço IP correspondente.

  O servidor que está tentando entregar a mensagem deve ter o registro de nomes configurado corretamente, de forma que o nome da estação possa ser resolvido em um endereço IP. Caso sua estação não tenha um registro DNS configurado, utilize o servidor de correio eletrônico do seu provedor de serviços.

• Sua mensagem teve uma identificação que terminava com o conjunto de caracteres “localhost”.

  Alguns clientes de correio eletrônico geram ID - identificações - das mensagens de forma imprópria. Nesse caso, o seu servidor de correio deve redefinir o ID da mensagem, ou você deve reconfigura-lo de modo que ele gere tal identificação de forma aceitável.

O Projeto FreeBSD não permite acesso público a nenhum dos seus servidores, contudo algumas empresas oferecem acesso irrestrito à sistemas Unix. Os preços variam, e alguns serviços limitados podem ser disponibilizados.

A Arbornet, Inc, também conhecida como M-Net, provê acesso à sistemas Unix desde 1983. Inicialmente rodando sob um System III em arquitetura Altos, o site mudou seu sistema para BSD/OS em 1991. Em junho de 2000 o site mudou novamente seu sistema para FreeBSD. A M-Net pode ser acessada via telnet e SSH, e proporciona acesso básico a uma gama completa de softwares do FreeBSD. Contudo, o acesso à rede é limitado aos membros e patronos da instituição, que fazem doações à empresa, uma vez que a mesma é uma organização sem fins lucrativos. A M-Net também oferece um Boletim periódico e Chat interativo.

A Grex também oferece um acesso parecido com o da M-Net, inclusive com os mesmos serviços, contudo a máquina é uma Sun 4M e seu sistema Unix é o SunOS. Vale pela curiosidade, e para comparação entre os sistemas.

SUP significa Protocolo de Atualização de Programa (Software Update Protocol ), e foi desenvolvido pela CMU para manter suas árvores de desenvolvimento sempre sincronizadas. Nós utilizamos esse protocolo para manter alguns sites remotos em sincronia com os nossos servidores centrais de desenvolvimento.

SUP náo é amigável com a banda de tramissão (consome muita banda) , e por isso foi aposentado. Atualmente recomendados que você faça uso do CVSup para manter seus fontes atualizados.

Ele não tem um nome, é simplesmente chamado de “the BSD daemon”. Se você insiste em dar um nome à ele, por gentileza, chame-o de “beastie” ;-) Note que “beastie” se pronuncia “BSD”.

Você pode saber mais sobre o BSD daemon na sua home page.

Talvez. O BSD daemon é de direitos autorais de Marshall Kirk McKusick. Você deve pedir a permissão do McKusick para usar a imagem do BSD Daemon, e pedir para saber os termos de utilização da figura pública do nosso querido capetinha ;-)

Resumindo, você pode fazer uso da imagem dele, dependendo da maneira, para uso pessoal, por exemplo. Se os créditos apropriados forem dados, tudo bem. Para fazer uso comercial da imagem, ai sim você deve falar com o McKusick, e dar uma olhada na home page do BSD Daemon para mais detalhes..

Você vai encontrar algumas figuras em eps e Xfig sob o diretório /usr/share/examples/BSD_daemon/.

MFC é um acrônimo para “obtido a partir do ramo -CURRENT” (Merged From -CURRENT). É usado nos logs do CVS para identificar uma mudança que seja originada e migrada da série de desenvolvimento (-CURRENT) para série estável (-STABLE).

O significado da sigla BSD é algo, em uma língua secreta que apenas os membros podem saber. Literalmente não seria possível traduzir BSD para uma língua que você pudesse entender, mas poderíamos tentar explicar seu significado como algo bem próximo de “Equipe de Fórmula-1”, “Penguins são aperitivos saborosos”, e também “Nós temos mais senso de humor do que o Linux”. :-)

A versão séria é que BSD é um acrônimo para “Berkeley Software Distribution”, que é o nome que o Grupo de Pesquisa de Ciência da Computação da Universidade de Berkeley - Berkeley CSRG (Computer Systems Research Group) - escolheu para sua própria distribuição do Unix.

É o Princípio de Menor Alteração. Significa que durante o processo de desenvolvimento do FreeBSD, toda e qualquer modificação que seja visível para o usuário, deve ser menos surpreendente possível, mantendo assim uma compatibilidade prévia com a forma de utilização do sistema. Por exemplo, não se pode alterar arbitráriamente as variáveis dos scripts de configuração do sistema, em /etc/defaults/rc.conf, pois esse tipo de ação violaria a POLA. O desenvolvimento do FreeBSD apenas considera POLA quando as alterações são visíveis pelo usuário.

Um repo-copy (que é uma forma breve de chamar um “repository copy”) é simplesmente a cópia direta de arquivos em um repositório CVS.

Sem um repo-copy, uma alteração por parte de algum mantenedor, se tornaria uma cópia comum, originada via cvs, seguida de um rm para deletar o arquivo original que tivesse sido modificado.

Esse processo contudo, resulta em uma não constatação histórica do arquivo antigo, nos novos registros de log. O Projeto FreeBSD considera extremamente importante a manutenção desse histórico, e por isso as cópias de repositório são frequentemente utilizadas. Nesse processo, um dos repositórios centrais vai copiar os arquivos diretamente para outro repositório, e não simplesmente fazer uma sincronia com o programa cvs(1).

A resposta mais curta, é que você não deve. A resposta longa é que, só porque você é capaz de fazer quarto para guardar sua própria bicicleta, você não pode fazer as outras pessoas pararem de construir seus próprios quartinhos também, simplesmente porque você não gosta da cor que as pessoas os pintam. Essa metáfora indica que você não tem que argumentar nem reclamar sobre cada coisinha, só porque tem conhecimento o bastante para critica-la. Algumas pessoas dizem que a quantidade de barulho provocada por uma alteração é inversamente proporcional à complexidade da mudança.

A resposta ainda mais completa, e maior, é que, depois de muita discussão sobre quando o sleep(1) deveria trabalhar com argumentos de segundos fracionados, Poul-Henning Kamp <phk@FreeBSD.org> enviou uma mensagem, longa, chamada de “Um quarto de bicicleta (qualquer cor serve) em um gramado mais verde...”. As partes devidas da mensagem estão citadas abaixo.

Na verdade, um "quartinho de bicicletas" ou "barracão de bicicletas" é uma tradução literal para a expressão “bikeshed”; comumente utilizada na língua inglesa. Um “bikeshed”, no significado definido pelo dicionário norte americano é um pequeno quarto ou barração não raramente encontrado no fundo de uma casa, que é utilizado para guardar bicicletas e outras coisas pequenas. Normalmente os norte americanos constroem esses quartinhos eles mesmos, de madeira, no fundo de suas casas ou próximos à garagem de automóveis. A expressão é normalmente utilizada pelos desenvolvedores do FreeBSD quando se começa uma discussão sobre algum assunto que não é tão importante para o bom funcionamento de alguma outra coisa, como por exemplo, qual a importância da cor de um quartinho de bicicletas, quando o mesmo já está construído e servindo bem ao seu propósito?