Capítulo 17. As gracinhas do FreeBSD

17.1. Quão fresco é o FreeBSD?
17.2. Quem está arranhando meus pentes de memória??
17.3. Quantos FreeBSD hackers são necessários para trocar uma lâmpada?
17.4. Para onde vão os dados que são escritos no dispositivo /dev/null ?

17.1.

Quão fresco é o FreeBSD?

P. Alguém já fez algum tipo de teste de temperatura ao rodar o FreeBSD? Eu sei que o Linux costuma ser mais fresco que o DOS, mas nunca ouvi falar nada a respeito do FreeBSD. Parece que ele é um sistema muito caliente!

R. Não, mas nós já fizemos vários testes de sabor com usuários vendados que, além de tudo, haviam tomado 250 microgramas de LSD-25. 35% dos voluntários disseram que o FreeBSD tinha um sabor parecido com laranja, enquanto o Linux tinha sabor de névoa púrpura. Nenhum dos dois grupos comentou nada significante sobre a variação de temperatura. Eventualmente, tivemos que jogar o resultado desses testes fora, já que descobrimos que vários desses voluntários estavam vagando fora do quarto, prejudicando os resultados. Acreditamos que hoje, a maioria desses voluntários trabalhe na Apple. Eles devem estar criando novas interfaces gráficas do tipo arranha e cheira. É um trabalho divertido e clássico, do qual nós fazemos parte!

Falando sério, o FreeBSD e o Linux usam as instruções HLT (halt) quando o sistema está inativo. Isto diminui consideravelmente o consumo de energia e, conseqüentemente, o aquecimento que ele proporciona. Além disso, se seu sistema possui APM (sistema avançado de gerenciamento de energia) configurado, o FreeBSD coloca a CPU em modo de consumo menor de energia.

17.2.

Quem está arranhando meus pentes de memória??

P. Existe alguma bruxaria que o FreeBSD faz ao compilar o kernel que, por ventura, estaria fazendo meus pentes de memória fazer barulhos estranhos, como se estivessem sendo arranhados? Durante a compilação do sistema (e um pouquinho depois, assim que a unidade de disquete é reconhecida, e após a inicialização também), um barulho estranho de arranhos começa a emanar de algum lugar que parece ser os pentes de memória.

R. Claro! Com muita frequência, você vai ouvir falar dos daemons na documentação do BSD. O que a maioria das pessoas não sabem é que essa é uma referência genuína às entidades não-corporais que estão possuindo o seu computador. O barulho que parece o som de alguma coisa sendo arranhada, na verdade são sussuros em tons extremamente agudos que os daemônios emanam, ao decidir entre si as melhores maneiras de tratar as várias tarefas referentes à administração do seu sistema.

Se o barulho te dominar, um bom fdisk /mbr no DOS pode fazer você se livrar dos sons, mas não se surpreenda se a reação dos daemons forem adversas, ao tentar evitar que você faça isso. Na verdade, há qualquer momento, é possível que você ouça a voz satânica do Bill Gates pelo auto-falante interno do seu PC. Se isso acontecer, CORRA! Corra sem parar e não olhe para trás por qualquer que seja o motivo! Depois de se liberarem das influências contrastantes dos daemons BSD, os demônios gêmeos do DOS e do Windows costumam ter sucesso ao repossuir total controle do seu computador, e depois disso, o tempo garantirá que eles consigam a dominação total da sua alma. Agora que você já conhece a verdade, esperamos que sua escolha seja conviver com os barulhinos agudos. Ou não?

17.3.

Quantos FreeBSD hackers são necessários para trocar uma lâmpada?

Mil cento e sessenta e nove:

Vinte e três para reclamarem no -CURRENT que estão sem luz;

Quatro para dizer que é um problema na configuração, e que essa pergunta deveria ser feita na freebsd-questions;

Três para enviar Relatório de Problemas sobre a lâmpada, dos quais ao menos um, não está completamente concluído, e consiste apenas de um breve tá escuro;

Um para adicionar uma lâmpada que nunca foi testada, que danifica todo o buildworld e depois de 5 minutos tem que ser retirada;

Oito para reclamarem para os autores dos Relatórios de Problemas por não ter incluído correções em seus relatórios;

Cinco para reclamar que o buildworld não está funcionando;

Trinta e um para responder que funciona para eles, e que os problemáticos devem ter feito CVSup na hora errada;

Um para enviar uma correção para a nova lâmpada na freebsd-hackers;

Um para reclamar que ele tinha correções para essa lâmpada há 3 anos, mas que quando elas foram enviadas para o -CURRENT, foram simplesmente ignoradas, e que sua experiência com o sistema de Relatório de Problemas não foram as melhores possíveis; além disso a nova lâmpada proposta não era reflexiva;

Trinta e sete para gritarem em alto e bom som que as lâmpadas não fazem parte da base do sistema, e que os desenvolvedores não tem o direito de sair fazendo esse tipo de coisa sem antes consultar a comunidade, e O QUE O -CORE ESTA FAZENDO SOBRE ISSO!?

Duzendos para reclamar da cor do quartinho de bicicletas;

Três para dizer que a correção enviada não está de acordo com os padrões que o código do kernel deve ter, conforme documentado na página de manual do style(9);

Dezessete para reclamar que a nova lâmpada proposta está licenciada sob a Licença Pública Geral GNU (GPL);

Quinhentos e oitenta e seis para entrarem de corpo e alma em uma discussão sobre as vantagens comparativas entre a licença Pública Geral GNU (GPL), a licença BSD, a licença do MIT, a NPL e a higiene pessoal dos fundadores da Free Software Foundation;

Sete para copiar vários trechos da discussão para a lista de discussão freebsd-chat e para a freebsd-advocacy;

Um para trocar a nova lâmpada sugerida, apesar de a nova brilha bem menos que a antiga;

Dois para retirarem a lâmpada furiosos, dizendo que o FreeBSD está melhor no escuro do que com uma lâmpada tão fraca;

Quarenta e seis para contestarem vorazmente sobre a retirada da lâmpada fraca e escreverem um relatório para o -core;

Onze para dar a idéia de criar uma lâmpada menorzinha, que poderia caber no Tamagotchi deles, se um dia nós decidirmos portar o FreeBSD para tal plataforma;

Setenta e três para reclamar da razão sinal versus ruído na freebsd-chat e na freebsd-hackers, e se retirarem das listas em protesto;

Treze para enviarem mensagens com o conteúdo "unsubscribe", "Como eu saio da lista?", ou "Por favor, me tirem da lista", seguidas do rodapé tradicional do servidor de discussão com as instruções para sair da lista;

Um, para adicionar uma nova lâmpada que funciona bem, enquanto todos os outros estão ocupados demais com a discussão para perceber que alguém já trocou a lâmpada por uma funcional;

Trinta e um para afirmar que a nova lâmpada brilha em média 0.364% mais, se comparada com as lâmpadas TenDRA (contudo, ela terá que ser refeita em formato de cubo) e que o FreeBSD deveria mudar para TenDRA ao invés do GCC;

Um para reclamar que a nova lâmpada não é honesta;

Nove (incluindo aqueles que enviaram os Relatórios de Problemas) para perguntar o que significa MFC?;

Cinquenta e sete para reclamar que ficaram no escuro por duas semanas até que a lâmpada fosse trocada.

Um adendo do Nik Clayton:

Eu estava rindo um bocado aqui.

Aí pensei, "Peraí, não deveria ter ao menos '1 para documentar a nova lâmpada' em algum lugar?

Daí eu fui iluminado :-)

17.4.

Para onde vão os dados que são escritos no dispositivo /dev/null ?

Esses dados são enviados para um dissipador especial da CPU que os converte em calor, para que depois sejam ventilados pelo cooler do computador. É por isso que o esfriamento do processador é cada vez mais importante; quanto mais rápido os processadores se tornam, menos importância os usuários dão à seus dados, por isso cada vez mais lixo é enviado para o /dev/null, gerando um superaquecimento das CPUs. Se o /dev/null for apagado (dessa forma desabilitando o dissipador de dados da CPU), o sistema vai rodar a uma temperatura mais amena. Contudo, o computador vai manter tanto lixo inútil existente, que o sistema vai logo começar a falhar. Se você tiver uma conexão de rede bem rápida, dá para resfriar o computador lendo todos os dados criados na /dev/random e enviando-os para algum lugar da rede. Contudo existe o risco de superaquecer sua rede ou do Provedor de Serviço Internet ficar meio bravo com você, já que todo esse calor normalmente é recebido pelo equipamento do provedor. Mas não se preocupe, os provedores tem grandes ventiladores para esfriar suas máquinas, então se você não insistir nisso com muita frequência, vai ficar tudo bem.

Adendo de Paul Robinson:

Existem outros métodos. Como todo bom administrador de sistemas sabe, faz parte da prática comum enviar dados das mais variadas espécies para a tela. Isto mantêm todos os pixies (pixie significa fadinhas em inglês) de tela felizes. Os pixies de tela (normalmente escritos com erro de ortografia, como 'pixels') são divididos de acordo com o tipo de boné que eles usam (vermelho, verde ou azul) e costumam aparecer ou sumir (mostrando a cor de seus bonés) sempre que eles ganham alguma coisinha para comer. As placas de vídeo transformam os dados em comida de pixies, e manda essa comida para eles. Quanto mais cara for a placa de vídeo, melhor é a qualidade da comida. Dessa forma, mais felizes ficam os pixies. Os pixies também precisam ser constantemente estimulados – é para isso que existem as proteções de telas.

Então, para seguir a sugestão anterior, é interessante mandar todos os dados que saírem do /dev/random para a tela do console, para alimentar os pixies. Isso não causa nenhum aquecimento do computador, e em contrapartida, faz os pixies viverem mais felizes, e ainda pode ser que faça você se livrar rapidamente de todos os dados existentes no /dev/random, mesmo considerando que a tela fique um pouco confusa.

Como um ex-administrador de um provedor que teve algumas más experiências tentando manter a estabilidade da temperatura da sala dos servidores, eu recomendo sinceramente que as pessoas não tentem enviar todos os seus dados para a rede. Existem umas pequenas fadinhas encantadas que fazem a alternância dos pacotes de redes, e que fazem o roteamento desses mesmos pacotes. Algumas vezes essas fadinhas ficam meio revoltadas com os usuários malvados que ficam mandando seus dados inúteis para a rede.

Este, e outros documentos, podem ser obtidos em ftp://ftp.FreeBSD.org/pub/FreeBSD/doc/

Para perguntas sobre FreeBSD, leia a documentação antes de contatar <questions@FreeBSD.org>.

Para perguntas sobre esta documentação, envie e-mail para <doc@FreeBSD.org>.