Canto do Daniel

Minha instalação do Ubuntu estava acusando pouco espaço disponível em /usr. Era uma partição de 15GB e, ainda assim, só tinha cerca de 600MB livres.

Como eu tinha exagerado no tamanho de /var, eu decidi reduzir o seu espaço (usando gparted) e criar uma nova partição para /usr/share, o que me daria cerca de 6GB de espaço disponível em /usr.

Tudo funcionou direitinho. Segui meu dia e, depois de algumas horas de trabalhar sem nenhum problema, passei a uma tarefa diferente. Estou lecionando e nao tinha ainda feito o upload dos slides para os alunos. Entao, abri a apresentação no Impress (o "Powerpointer" do Libre-Office) e grande parte do texto tinha desaparecido. Eu ainda tinha figuras, alguns títulos e umas caixas de texto, mas o conteúdo mesmo tinha sumido.

Baixei backups, nada. Aí, depois de uma xícara de café para limpar a mente, eu me toquei de que o problema poderia ser com as mundanças que eu tinha feito no sistema de arquivos. Para entender, olhei os slides de novo. Os textos que sumiram usavam fontes específicas. Por exemplo, eu usava courier para fragmentos de código, e, em um caso que eu tinha esquecido, o código ainda estava lá. Agora, Adivinha onde as fontes são armazenadas? Isso mesmo: /usr/share/fonts. As coisas começaram a fazer sentido.

Então, depois de procurar por soluções, eu achei que existe um cache de fontes e eu concluí que mover /usr/share para outra partição deve ter corrompido o tal cache. Assim, eu reconstruí o cache e: ta-ra! Funcionou.

Se você encontrar um problema parecido, o comando para reconstruir o cache é o seguinte:

Este erro deve aparecer quando voce adiciona um repositório às suas fontes (sources). Por examplo, no meu caso, eu adicionei Gnome3 e o repositório era ppa.lauchpad.net.

Depois de executar apt-get update, eu recebi a seguinte mensagem de erro:



Onde ≪ASSINATURA≫ era a assinatura do repositório e consiste da representação em hexadecimal de um número bem grande.

Este erro occoreu porque eu adicionei o repositório, mas não a sua respectiva chave pública. Meu sistema não conseguia verificar se estava se comunicando com o repositório correto ou com um falso.

Para corrigir, nós temos que conseguir a chave from alguma fonte em que possamos confiar. No meu caso, peguei do próprio Ubuntu. (Eu estou usando o sistema deles, então eu já meio que confiio neles de qualquer forma.)

O comando para adicionar a chave é o seguinte:



Na verdade, usei o último comando (apt-get update) apenas para confirmar que estava tudo correto. ;)

Pela primeira vez em muito tempo, resolvi sair um pouco da minha "zona de conforto" e testar uma distribuição Linux que não fosse baseada em Ubuntu ou Debian. Eu precisava mesmo mudar minha instalação de 32 para 64 bits, então aproveitei a desculpa.

Resolvi testar Mageia, uma distribuição derivada do Mandriva (da empresa que se formou quando a francesa Mandrake adquiriu a brasileira Conectiva), da mesma forma que o Fedora derivou do RedHat.

Infelizmente, a experiência não foi muito agradável. O DVD de instalação não funcionou, quando eu iniciava, tinha erro no ambiente gráfico. Consegui instalar a partir do CD Live. Mas, fora a minha falta de familiaridade (por exemplo, "cadê o equivalente ao apt-get?"), achei o ambiente muito instável.

Testei o Enlightenment (E17)... Honestamente, achei bonitinho mas ordinário. Muito lento e com excesso de animações. Creio que com uma ferramenta de configuração mais eficiente e que permita "sintonia fina" talvez seja uma alternativa interessante.

Como uma vez o Sheldon disse: "Existe uma razão do porquê é chamada 'Zona de Conforto'". Assim, pelo menos por enquanto, estou voltando pra "casa". Hoje a tarde/noite eu reinstalo o Linux Mint 13 (agora 64 bits) rodando LXDE. Quando o tempo permitir, talvez eu faço outra aventura em alguma outra distro "estranha".

Alguns usuários de Linux (incluindo eu mesmo) têm tentado sem sucesso executar um comando via SSH, por exemplo, na forma:

ssh user@host mycommand

O problema parece ser que "mycommand" está em um diretório que não está no PATH. Entretanto, quando eles conectam normalmente, eles podem checar e o diretório está listado em PATH.

O que acontece é que a maioria destes usuários (de novo, me incluindo) atualizam a variável PATH no arquivo/script .bashrc e, aparentemente, o arquivo .bashrc não é executando de forma "não interativa" pelo ssh.

Depois de procurar por um bom tempo, achei muitas pessoas sugerindo checar se o .bashrc era chamado pelo arquivo .profile ou .bash_profile ou algo assim. Bem... isso não resolvia meu problema.

O que acontece de fato é que .bashrc estava sendo chamado (ou "sourced", como alguns chamam) pelo ssh, mas os caras da distro decidiram adicionar as seguintes linhas no arquivo:

# If not running interactively, don't do anything

[ -z "$PS1" ] && return

Basicamente, o teste acima somente permite a execução do resto do script se executando por um shell interativo, portanto não funciona para minhas necessidades. Porque isto está lá? Não tenho a menor idéia... mas... de qualquer forma... comentei o teste e tudo funcionou perfeitamente.