Problema de Lógica: As pérolas do rajá

Um rajá deixou às suas filhas certo número de pérolas e determinou que a divisão se fizesse do seguinte modo: a filha mais velha tiraria 1 pérola e um sétimo do que restasse; viria, depois, a segunda e tomaria para si 2 pérolas e um sétimo do restante; a seguir a terceira jovem receberia 3 pérolas e um sétimo do que restasse. E assim sucessivamente. A divisão proposta pelo velho rajá era justa e perfeita. Feita a partilha, cada uma das herdeiras recebeu o mesmo número de pérolas. Pergunta-se: Qual o número de pérolas? Quantas são as filhas do rajá?






RESPOSTA






Seja x o número total de pérolas do rajá e q1, q2, q3 etc. as quantidades para cada filha. Portanto x = q1+q2+q3 etc.

A primeira filha retirou 1 pérola mais 1/7 do restante:

q1 = 1 + 1/7 * (x-1) = (x+6)/7

Então restaram:

x - q1 = x - ((x+6)/7) = (6x-6)/7

A segunda retirou 2 pérolas mais 1/7 do restante:

q2 = 2 + 1/7 * ((6x-6)/7 - 2) = (6x+78)/49

Poderíamos agora calcular o restante e a quantidade para a terceira filha mas não é necessário. Como sabemos que as herdeiras receberam o mesmo número de pérolas, então, q1=q2=q3 etc. Assim, podemos igualar a quantidade q1 com q2 e encontrar o valor do número total de pérolas:

q1 = q2
(x+6)/7 = (6x+78)/49
x = 36

As pérolas eram em número de 36 e foram repartidas por 6 filhas. A primeira tirou 1 pérola e mais um sétimo de 35, isto é, 5; logo, tirou 6 pérolas e deixou 30. A segunda, das 30 que encontrou, tirou 2 mais um sétimo de 28, que é 4; logo, tirou 6 e deixou 24. A terceira, das 24 que encontrou, tirou 3 mais um sétimo de 21, ou 3. Tirou portanto 6, deixando 18 de resto. A quarta, das 18 que encontrou, tirou 4 mais um sétimo de 14. E um sétimo de 14 é 2, recebendo também 6 pérolas. A quinta encontrou 12 pérolas e retirou 5 e um sétimo de 7, isto é, 1; logo tirou 6. A sexta filha recebeu, por fim, as 6 pérolas restantes.

Magnitude de objetos celestes

A magnitude é uma medida do brilho de um objeto celeste. Números mais altos de magnitudes representam objetos menos brilhantes, números mais baixos de magnitudes representam objetos mais brilhantes e números negativos de magnitude indicam brilho extremo.

O primeiro sistema de medida do brilho de objetos celestes foi desenvolvido pelo astrônomo grego Hiparco, no século II a.C. Ele verificou que as estrelas poderiam ser classificadas de acordo com o brilho que apresentavam quando observadas a olho nu. Sem meios de medir sua radiação, ele escolheu visualmente as mais brilhantes e as definiu como de grandeza 1. As um pouco mais fracas, chamou de grandeza 2, e assim por diante até chegar às estrelas que mal podia ver, que classificou como grandeza 6.

Naquela época a intensidade visual era associada ao tamanho dos objetos, desta forma utilizava-se a palavra grandeza. Atualmente, a intensidade visual está relacionada à distância de um objeto, não tendo relação com seu tamanho e brilho intrínseco e o termo adotado passou a ser magnitude. O brilho que um objetos celeste aparenta ter, quando visto a olho nu a partir da Terra, determina sua magnitude aparente ou visual. Já a medida real ou do seu brilho intrínseco é definida pela magnitude absoluta.

O sistema quantitativo atual foi desenvolvido em 1856 pelo astrônomo inglês Norman Robert Pogson, que procurou criar um sistema que concordasse tanto quanto possível com as antigas medições qualitativas feitas pelos gregos. Com o auxílio de um fotômetro, Pogson elaborou um modelo matemático para dar conta do sistema de magnitudes.

A expressão que dá a magnitude visual ou aparente de uma estrela em termos de sua luminosidade é conhecida como fórmula de Pogson e é escrita como:

m = -2,5 log F + C

Onde m é a magnitude aparente ou visual da estrela, F é a luminosidade da estrela recebida por um detector colocado sobre a superfície da Terra, e C é a constante usada para definir o zero da escala de magnitude, baseada na magnitude aparente da estrela Vega.

A equação de Pogson mostra que a escala de magnitudes é uma relação logarítmica. A regra utilizada por esta escala é tal que uma diminuição sucessiva de uma unidade em magnitude representa um aumento no brilho aparente por um fator de 2,512. Deste modo uma diferença de 5 magnitudes corresponde a um aumento de 100 vezes no brilho do objeto celeste. Trata-se da medição feita por Pogson através do fotômetro, onde observou-se que a diferença de brilho entre uma estrela de grandeza 1 e uma de grandeza 6 era de aproximadamente 100 vezes.

A magnitude aparente não nos dá uma ideia do brilho verdadeiro de um objeto, que às vezes parece fraco devido à grande distância que se encontra, enquanto outros nos parecem muito brilhantes porque estão muito mais perto. A magnitude absoluta é o brilho que os objetos apresentariam, se estivessem a uma mesma distância, padronizada em 10 parsecs (1 parsec = 30,857x10^12 km). Deste modo, vemos que a magnitude absoluta mede quão brilhante um objeto apareceria para nós se ele fosse tirado de sua posição verdadeira e colocado a uma distância padrão de 10 parsecs, ou aproximadamente 32,6 anos-luz.

Se a distância real de uma estrela é d parsecs, sua magnitude absoluta M e sua magnitude aparente m estão relacionadas pela equação:

M = m - 5 log (d/10)

Abaixo uma tabela com as estrelas mais brilhantes de acordo com a magnitude aparente e respectiva magnitude absoluta e distância à Terra:

Estrela      magnitude      magnitude      distância à Terra
             aparente       absoluta       em parsecs

Sol          -26,74          4,83            0,00000485
Sirius        -1,46          1,43            2,64
Canopus       -0,72         -5,63           96
Arcturus      -0,04         -0,29           11,24
Vega           0,03          0,58            7,76
Rigel          0,18         -6,72          240
Procyon        0,34          2,63            3,49
Betelgeuse     0,42         -6,05          197

A visão humana, sem instrumentos, é capaz de enxergar objetos até a sexta magnitude, com o auxílio de um binóculo ou de um telescópio o alcance torna-se maior, por exemplo o telescópio Hubble detecta objetos até a trigésima magnitude aparente.

Execução de aplicações gráficas remotas pelo redirecionamento do X11 com o SSH

O protocolo SSH possui a habilidade de redirecionar seguramente aplicações gráficas, do ambiente X Window, para uma conexão SSH criptografada. Assim, a aplicação gráfica é executada na máquina remota e sua janela é exibida na máquina local, em um tráfego de rede protegido.

Se a máquina remota possui o sistema Linux, que é o se será abordado neste artigo, a implementação do "X11 Forwarding" torna-se simples e os clientes poderão ser tanto sistemas Linux como Windows.

Para isto poder acontecer são necessários alguns pré-requisitos. Primeiro, na máquina remota o servidor X deve estar em estado de execução. Segundo, o sistema da máquina remota precisa estar configurado para permitir o acesso por SSH. E finalmente, o servidor SSH (SSHd) da máquina remota e o cliente SSH da máquina local precisam estar configurados para permitir o X11 Forwarding.

O primeiro e o segundo pré-requisitos não serão abordados neste artigo, vamos partir do terceiro.

A configuração do servidor SSH se faz pelo arquivo "/etc/ssh/sshd_config". Neste arquivo encontram-se duas linhas que devem ter seus argumentos como mostrado abaixo, para ativar o redirecionamento do X11:

X11Forwarding yes
X11DisplayOffset 10

O parâmetro "X11Forwarding" marcado com "yes" especifica que o redirecionamento do X11 está permitido. O parâmetro "X11DisplayOffset" especifica o primeiro valor disponível para redirecionamento do X11 pelo servidor SSH, prevenindo que o SSHd interfira nos servidores X11 reais. O padrão é 10.

Basta reiniciar o serviço do SSHd para concluir esta parte da configuração da máquina remota. Agora vamos para o cliente, que é a máquina local onde irá receber as janelas das aplicações gráficas.

Em um cliente com sistema Linux, existem algumas formas de ativar o X11 Forwarding em uma sessão SSH. Uma é editar o arquivo de configuração "/etc/ssh/ssh_config" e alterar duas linhas para "ForwardX11 yes" e "ForwardX11Trusted yes". Esta forma ativa o recurso permanentemente para todos os usuários que forem utilizar o SSH. Uma outra forma é diretamente na linha de comando do SSH, com os parâmetros -X ou -Y. O parâmetro -X equivale ao "ForwardX11 yes" e o parâmetro -Y ao "ForwardX11Trusted yes".

Temos então duas classes de clientes, com o redirecionamento não-confiável do X11 e com o redirecionamento confiável do X11, respectivamente -X e -Y. O redirecionamento confiável do X11 significa que o cliente confia no servidor X, no qual está conectando pelo SSH, e que então neste servidor X não há qualquer programa malicioso como keylogger, screenshot ou algo que vá espionar sua conexão. O redirecionamento não-confiável do X11 significa uma conexão para um sistema desconhecido ou inseguro. Este tipo de conexão gera um cookie com o xauth e utiliza uma extensão de segurança para limitar o acesso. Algumas aplicações podem não funcionar neste modo não-confiável por causa destas limitações na segurança.

Assim, em um cliente com sistema Linux devemos executar o cliente SSH para abrir um terminal do sistema remoto e qualquer aplicação gráfica que for executada por este terminal será aberta na área de trabalho do cliente, que é a máquina local. Segue um exemplo de linha de comando para o SSH:

$ ssh -CY -c blowfish 192.168.1.102

Outros parâmetros podem ser utilizados na linha de comando do SSH, de acordo com a necessidade ou preferência. Por exemplo o parâmetro -C ativa a compactação de dados na transferência pela rede, o parâmetro -c especifica a cifra de criptografia. Este assunto sai do escopo deste artigo, é só um lembrete.

Em um cliente com sistema MS Windows são necessários um servidor X, para receber as janelas das aplicações remotas, e um cliente SSH, para estabelecer a conexão segura com o servidor remoto.

Um servidor X para Windows compatível com o X11 é o Xming (http://www.straightrunning.com/XmingNotes/). Sem entrar em muitos detalhes, pois o procedimento é fácil, instale e execute o Xming. Seu ícone aparecerá na barra de tarefas. Posicionando o cursor sobre seu ícone, o software mostra o endereço do servidor X no cliente Windows, algo como "Xming Server:0.0".

O PuTTY (http://www.chiark.greenend.org.uk/~sgtatham/putty/) é uma implementação gratuita de um cliente SSH para Windows. Não requer instalação, basta executá-lo para abrir sua janela de configuração. Na janela de configuração do PuTTY, na categoria "Session" escreva o nome da máquina ou o IP em "Host Name (or IP address)" e a porta se for o caso. Na categoria "Connection/SSH/X11" marque a quadrícula "Enable X11 forwarding" e em "X display location" escreva sem as aspas "localhost:0.0", que é o endereço do servidor X instalado no cliente Windows. Concluída esta configuração, basta clicar no botão "Open" para o PuTTY abrir a janela do terminal remoto. Qualquer aplicação gráfica que for executada por este terminal será aberta na área de trabalho do cliente Windows.

Como visto, pela ferramenta SSH é possível não só executar aplicações em modo texto como também aplicações gráficas. A administração de sistemas remotos torna-se bastante completa com este recurso a mais. Consulte as documentações das ferramentas citadas neste artigo para mais informações.

I don't want directions

Adaptando o mundo moderno aos costumes antigos...

* clique na imagem para exibi-la em tamanho natural.

Referência: XKCD (http://xkcd.com/783/)

Usando o msmtp com o Mutt para envio de anexos

O Mutt é um programa que permite aos usuários ler, salvar e compor mensagens de e-mail, em um ambiente em modo texto. Programas deste tipo são formalmente chamados de MUA (Mail User Agent).

Para o envio de e-mail pela linha de comando com arquivos binários em anexo, o resultado é mais garantido quando utiliza-se o Mutt para formatar a mensagem. O Mutt trata adequadamente os tipos MIME e assim o recebimento do arquivo binário é devidamente reconhecido pelo programa cliente do destinatário.

O Mutt pode trabalhar com o programa msmtp para o envio das mensagens, ao invés de sua função interna de SMTP ou do sendmail, para isso é necessária uma simples configuração no seu arquivo ~/.muttrc, desde que o programa msmtp esteja devidamente configurado (veja em: http://dan-scientia.blogspot.com/2010/08/enviando-email-pela-linha-de-comando.html).

Um exemplo de configuração para o ~/.muttrc é apresentado a seguir:

set sendmail = "/usr/bin/msmtp -a gmail"
set realname = "Nome do Usuario"
set from = usuario@gmail.com
set use_from=yes
set envelope_from=yes

Toda a construção do e-mail será agora pela linha de comando do Mutt. Os principais parâmetros de entrada são:

-a arquivo
     Anexa um arquivo na mensagem usando MIME.
-b endereço
     Especifica o endereço de e-mail para cópia oculta (Bcc).
-c endereço
     Especifica o endereço de e-mail para cópia (Cc).
-H rascunho
     Especifica um arquivo de rascunho com os dados do cabeçalho e corpo da mensagem.
-i arquivo
     Especifica um arquivo texto para incluir no corpo da mensagem.
-s assunto
     Especifica o assunto da mensagem.
--   Marca o final dos parâmetros. Obrigatório quando usa-se o parâmetro -a pois separa os nomes dos arquivos dos endereços de e-mail.

Para compor uma nova mensagem pode-se usar uma linha de comando semelhante a abaixo:

$ mutt -c fulano@provedor.com.br -i arquivo.txt -s "Assunto da mensagem" -a foto.jpg -- destinatario@provedor.com.br

Com o comando acima o Mutt abrirá um editor para confirmar os itens de cabeçalho e corpo da mensagem. Para automatizar o envio do e-mail e assim não abrir o editor do Mutt, podemos utilizar uma mensagem pré preparada em um arquivo texto, para compor o corpo da mensagem, e direcioná-la para o programa Mutt:

$ cat mensagem.txt | mutt -c fulano@provedor.com.br -s "Assunto da mensagem" -a foto.jpg -- destinatario@provedor.com.br

O próximo exemplo faz uso do parâmetro -i para inserir o texto no corpo da mensagem porém direciona o dispositivo nulo (ele retorna uma indicação de final de arquivo) na edição do Mutt, para automatizar o envio.

$ mutt -c fulano@provedor.com.br -i mensagem.txt -s "Assunto da mensagem" -a foto.jpg -- destinatario@provedor.com.br < /dev/null

E o exemplo a seguir utiliza o parâmetro -H que recebe um arquivo texto contendo toda a estrutura para o cabeçalho e corpo do e-mail, chamado arquivo de rascunho:

$ mutt -H email.txt -a foto.jpg < /dev/null

O conteúdo para este arquivo de rascunho segue o modelo abaixo:

To: fulano@provedor.com.br, sicrano@provedor.com.br
Cc: beltrano@provedor.com.br
Bcc: johndoe@provedor.com.br
From: usuario@gmail.com
Subject: Assunto do e-mail

Texto do corpo da mensagem.

Outra opção para automatizar o envio é redigir a mensagem na própria linha de comando:

$ echo "Texto do corpo da mensagem." | mutt -c fulano@provedor.com.br -s "Assunto da mensagem" -a foto.jpg -- destinatario@provedor.com.br

O Mutt é um programa cliente de e-mail completo, com diversas diretivas para configuração e personalização. Seu ambiente, em modo texto, é controlado completamente pelo teclado e possui tudo o que é necessário para um software cliente de e-mail. Como visto neste artigo, somente por sua linha de comando já é possível enviar um e-mail automaticamente, isto pode ser útil em um shell script.

Se você acabar entrando no ambiente de edição do Mutt, será necessário conhecer as teclas dos comandos para operar o ambiente. Quem sabe num próximo artigo.

Mais informações em http://www.mutt.org/ ou nas páginas manuais do Mutt.

Enviando email pela linha de comando usando o msmtp

O msmtp é um cliente de SMTP que em seu modo de operação padrão transmite um e-mail para um servidor SMTP, por exemplo para seu provedor, que faz a entrega. Pode ser usado por um programa cliente de e-mail (MUA) e é compatível com o programa sendmail. Dentre outros atributos o msmtp pode trabalhar com diversos métodos de autenticação e com múltiplas contas de e-mail.

O msmtp é executado pela linha de comando e pode ser configurado por arquivo alcançável em todo o sistema (/etc/msmtprc), por arquivo restrito ao usuário (~/.msmtprc) ou diretamente por parâmetros na linha de comando. Um exemplo de conteúdo para o arquivo de configuração é o apresentado a seguir:

account gmail
host smtp.gmail.com
port 587
timeout off
protocol smtp
auto_from off
from usuario@gmail.com
maildomain gmail.com
auth on
user usuario
password suasenha
tls on
tls_starttls on
tls_certcheck off
logfile ~/.msmtp.log
syslog LOG_MAIL

account default: gmail

Este exemplo serve para o servidor SMTP do Gmail. Múltiplas contas podem ser configuradas neste arquivo, identificadas pela linha "account nome_da_conta". É recomemdável proteger o arquivo de configuração do msmtp com permissões de leitura e escrita somente para o próprio usuário (0600, -rw-------), senão a senha ficará exposta aos outros usuários.

O msmtp possui muitas opções para sua linha de comando mas basicamente o comando pode ser "msmtp " se o arquivo de configuração existir. Com este comando simples o programa inicia um prompt para a entrada do conteúdo do e-mail, para o cabeçalho e corpo. A combinação de teclas "Ctrl+D" encerra esta edição. Entretanto, pode ser mais prático utilizar um arquivo texto contendo toda esta estrutura de mensagem e direcioná-lo para a entrada padrão do msmtp. Um exemplo de como pode ser este arquivo texto é apresentado abaixo:

To: fulano@provedor.com.br, sicrano@provedor.com.br
Cc: beltrano@provedor.com.br
Bcc: johndoe@provedor.com.br
From: usuario@gmail.com
Subject: Assunto do e-mail

Texto do corpo da mensagem.

A linha de comando do msmtp ficaria então desta forma:

$ msmtp --read-recipients < email.txt

Para não utilizar um arquivo de configuração é necessário passar todos os dados do servidor SMTP pela linha de comando do msmtp. Aproveitando o exemplo da conta do Gmail mostrado anteriormente, a seguir está o exemplo da linha de comando equivalente:

$ msmtp --host=smtp.gmail.com --port=587 --timeout=off --protocol=smtp --auto-from=off --from=usuario@gmail.com --maildomain=gmail.com --auth=on --user=usuario --tls=on --tls-starttls=on --tls-certcheck=off --syslog=LOG_MAIL --read-recipients < email.txt

A senha do servidor não é passada pela linha de comando, ela é solicitada pelo msmtp em um prompt semelhante ao abaixo:

password for usuario at smtp.gmail.com:

Outros parâmetros poderão ser úteis, o parâmetro --file=arquivo é usado para indicar outro arquivo de configuração ao invés do padrão e --account=nomedaconta para indicar outra conta de e-mail ao invés da conta padrão.

O conteúdo de uma mensagem de e-mail é sempre em texto ASCII, porém é possível anexar um conteúdo binário no corpo da mensagem. Um arquivo binário pode ser codificado para o formato ASCII por ferramentas como o uuencode ou o uuenview, este último mais poderoso. A linha de comando para um e-mail com anexo binário pode ser como no exemplo a seguir:

$ (cat email.txt; uuenview foto.jpg) | msmtp --read-recipients

Neste exemplo tanto o conteúdo do arquivo email.txt como o resultado da codificação do arquivo foto.jpg são canalizados para a entrada padrão do comando msmtp. Contudo, aqui tem uma ressalva, o programa msmtp não trata garantidamente os tipos MIME e, dependendo do programa cliente ou provedor que irá receber a mensagem, o arquivo anexo poderá não ser reconhecido no recebimento. Por exemplo, em testes feitos por mim, contas do Gmail e do Yahoo receberam adequadamente mas a conta do Terra não. A solução garantida é utilizar outra ferramenta para formatar o e-mail e trabalhar em parceria com o msmtp, no envio. Uma boa ferramenta para linha de comando é o Mutt, que será descrito em um próximo artigo.

Mais informações em http://msmtp.sourceforge.net/ ou nas páginas manuais do msmtp.

O conhecimento comum e o equilíbrio de Nash

O conceito do conhecimento comum é a base na teoria dos jogos. A clássica teoria dos jogos assume que todo conhecimento é "conhecimento comum", exceto por partes específicas de informações que são percebidas assimetricamente, para justificar o conceito do equilíbrio de Nash. Um fato é de conhecimento comum se todos sabem o fato, todos sabem que todos sabem o fato, todos sabem que todos sabem que todos sabem o fato, e assim infinitamente. Se é de conhecimento comum que todos os jogadores são racionais, ou escolhem a melhor reação, então em condições apropriadas eles produzem um equilíbrio de Nash.

Por vários anos foi pensado que a existência de conhecimento comum da racionalidade para os jogadores no jogo era fundamental. Acontece que em um jogo com dois jogadores o conhecimento comum da racionalidade não é necessário como uma condição para estratégias que levem ao equilíbrio de Nash. Um exemplo é o dilema do prisioneiro, onde a pior estratégia para ambos conduz a um melhor resultado cooperativo, um equilíbrio de Nash.

Dilema do prisioneiro:

Dois suspeitos, A e B, são presos pela polícia. A polícia tem provas insuficientes para os condenar, mas, separando os prisioneiros, oferece a ambos o mesmo acordo: se um dos prisioneiros, confessando, testemunhar contra o outro e esse outro permanecer em silêncio, o que confessou sai livre enquanto o cúmplice silencioso cumpre 10 anos de sentença. Se ambos ficarem em silêncio, a polícia só pode condená-los a 6 meses de cadeia cada um. Se ambos traírem o comparsa, cada um leva 5 anos de cadeia. Cada prisioneiro faz a sua decisão sem saber que decisão o outro vai tomar, e nenhum tem certeza da decisão do outro. A questão que o dilema propõe é: o que vai acontecer? Como o prisioneiro vai reagir?

Existem alguns jogos divertidos que possuem equilíbrios de Nash que dependem do nível de recursão de "quem sabe de quem sabe o que". Os próximos problemas exploram este assunto.

O pai e os filhos:

Um pai honesto mas brincalhão disse a seus dois filhos responsáveis que ele colocou R$ 10, R$ 100, R$ 1.000 ou R$ 10.000, com igual probabilidade, em um envelope e dez vezes o tal dinheiro em outro envelope. Ele deu um envelope para cada filho. Um filho encontrou R$ 10.000 e o segundo R$ 1.000. O pai chamou cada um a parte e perguntou particularmente se ele gostaria de trocar. Cada um disse "sim". O pai relatou cada uma destas respostas para o outro irmão. Quantas vezes precisará o pai repetir este processo até que um dos filhos diga "não"?

As mulheres de Sevita:

Os Sevitãos vivem como famílias monogâmicas em um pequeno vilarejo onde literalmente todos sabem o que todos estão fazendo, literalmente em todo o tempo. A única assimetria informacional é que nenhuma esposa sabe se seu próprio marido é mulherengo, embora toda esposa saiba a conduta de todos os outros maridos no vilarejo. A punição para um marido mulherengo é ser marcado pela sua esposa com um M marrom na testa durante à noite enquanto dorme. Esta punição é somente imposta pela esposa que soube com convicção que seu marido é culpado.

Desnecessário anunciar, nenhum marido jamais foi marcado. Mas um dia uma mulher de outro vilarejo fez uma visita. Indo embora no dia seguinte, ela confidenciou para as mulheres de Sevita que agora há pelo menos um mulherengo no vilarejo. Nada aconteceu durante cinco dias. Mas na sexta noite um certo número de maridos foram marcados com o M marrom. Quantos maridos foram marcados? Quantos maridos mulherengos há neste lugar? Como pode isto acontecer, já que a mulher indo embora não disse para as mulheres de Sevita nada que elas já não saibam - que agora há pelo menos um mulherengo no meio delas?

O problema da Cor dos Olhos postado neste blog também é sobre este assunto (http://dan-scientia.blogspot.com/2009/08/problema-de-logica-cor-dos-olhos.html).