Já faz algum tempo que comprei uma máquina da STI, Semp Toshiba, do tipo "computador popular". Comprei pelo preço baixo e pelo fato de vir com Linux instalado (um é causa o outro, efeito, mas não sei qual é qual). Isso uns 3 anos atrás. Nunca fui muito adepto de equipamento pré-montado, mas nessa época já estava meio cansado de ficar entrando em boca-de-hardware na Santa Ifigênia pra montar um computador decente.
A grande surpresa foi a qualidade do acabamento do computador: teclado excelente e macio, mouse ótico, entradas de leitor pra cartões de memória (todos os tipos até onde testei), caixas de som com amplificador energizado via USB, 2 GB de RAM, 250 GB de disco SATA e drive gravador de DVD. Realmente um hardware legal (lembre-se que isso foi há 3 anos atrás).
Na época veio com Insigne Linux instalado. Acho que durou uns 5 minutos rodando, o tempo de olhar a cara do sistema, até eu instalar um Ubuntu por cima. Desde então tenho usado o mesmo com Linux 32 bits.
No final do ano passado, por volta de meados de dezembro, só então notei uma mensagem de hardware no boot: EM64T. Sabia que era um Core 2 duo, mas achei que era só isso. Com algumas mensagens no Twitter, algums amigos confirmaram que a CPU era mesmo 64 bits, mas recebi muitas críticas negativas sobre o mesmo em Linux, principalmente em relação à crashes de aplicativos, principalmente em sites com flash. Resolvi então manter os 32 bits.
Recentemente li um artigo dizendo que o Linux fracassou miseravelmente na arquitetura 64 bits. O texto realmente está certo na abordagem do Linux em relação à nova arquitetura: dizia-se que o Windows estava fadado ao esquecimento dos 32 bits e que Linux iria dominar o desktop pois sua migração era tão fácil quanto a instalação em uma torradeira. E o que vemos atualmente é exatamente o oposto disso: várias recomendações pra se manter Linux em 32 bits por questões de estabilidade. No ponto em que li essa frase, confesso que senti uma pontada de culpa, pra não dizer vergonha.
Por um problema com um aplicativo de VPN da empresa, não posso migrar meu laptop pra 64 bits (processador Intel Core i3) e tenho de continuar envergonhado, mas
já o meu desktop... resolvi arregaçar as mangas e instalar. Parti pra instalação do Ubuntu 10.10 em arquitetura AMD64.
Como sempre, dpkg salvou o dia com a lista de aplicativos previamente instalados (dpkg --get-selections >myselections). A migração, ou reinstalação, ocorreu sem demais problemas. Um backup do /etc, bases do mysql e do diretório /root e rapidamente tive o sistema restaurado, e em 64 bits.
Para batizar a *nova* máquina dei o nome de goosfraba, em homenagem ao filme do "tratamento de choque" com Jack Nicholson e Adam Sandler (final meio infeliz, mas em geral é engraçado).
Até o momento a goosfraba tem funcionado melhor que na arquitetura 32 bits: mais rápido. Tenho a sensação de que estava dirigindo uma Audi A3 turbo, mas que antes só colocava até a 4a marcha. E agora vou até a 7a. Mas espero problemas com o Flash Player, pois sei que apesar do Linux não ter fracassado em 64 bits, também não foi o sucesso desejado.
Referências:
[1] What happened to "World Domination 201"? (ou Linux fracassou miseravelmente em 64 bits)
Hoje, no meio das minhas férias, dei uma conectada na rede da empresa pra verificar uns mails (de uns amigos perdidos que mandaram pro endereço errado).
Por lá o comunicador oficial é o Lotus Sametime, da IBM. Sempre conectei utilizando o Pidgin, um dos melhores clientes multi-serviço para IMs que conheço, e utilizando o módulo meanwhile pra conectar no servidor de sametime. Qual não foi minha surpresa ao descobrir que o mesmo não funcionava mais. Apenas recebia uma mensagem de "Version Mismatch" no rodapé do Pidgin e a conexão se encerrava.
Felizmente encontrei fácil uma solução no site do Pidgin, no TT#12623. A solução sugere que o meanwhile seja configurado pra esconder sua identificação (hide), o que já era feito. Então editei o arquivo ~/.purple/accounts.xml e adicionei somente uma linha com a informação abaixo:
<settings>
<setting name='fake_client_id' type='bool'>1</setting>
<setting name='client_minor' type='int'>8511</setting>
<setting name='port' type='int'>1533</setting>
<setting name='force_login' type='bool'>1</setting>
<setting name='server' type='string'>sametime.internal.server.com</setting>
</settings>
Funcionou xuxu beleza. Reiniciei o Pidgin e imediatamente conectei e pude ver os contatos online.
Como já tinha comentado no post anterior, adquiri um laptop novo. Decidi fazer isso pra me livrar da chateação corporativa do laptop da empresa. Agora posso utilizar Linux ou FreeBSD, ou o que eu quiser, incondicionalmente, sem amolação. No momento estou com Linux, Ubuntu pra ser mais preciso, mas com certeza gostaria de rodar FreeBSD nele, o que não farei até que o suporte pra suspend/hibernate esteja mais maduro.
Devido às restrições dos aplicativos da empresa, que estão empacados em 32 bits, optei por utilizar Ubuntu X86 ao invés do AMD64. Se perdi desempenho, nem percebi. Habilitei o kernel com PAE, pra endereçar os 4 GB de memória e tudo está funcionando bem.
Mas vamos a uma descrição um pouco mais completa do laptop:
Nem vou detalhar sobre os drivers pois o Ubuntu, ou mais precisamente o Kubuntu, reconheceu tudo de primeira. Vídeo, webcam, wireless, tudo mesmo saiu funcionando com uma pequena exceção: o ACPI de eventos de bateria. No momento o sistema não detecta que está na tomada ou não, não ativando automaticamente os modos de conservação de energia.
Outro detalhe ruim é o teclado. Veio de novo num formato bizarro, não ABNT2, apesar do manual jurar ser um. Resolvi isso da forma mais lusitana possível (ou patolonização, pra quem conheçe o Patola), cobrindo as teclas - pra não me confundir - e utilizando o formato us_intl. Existiam outras opções, como re-mapear o teclado com xmodmap, mas deixar o teclado coberto ficou mais engraçado e ainda por cima evita que os "não iniciados" tentem usar meu laptop.
A bateria, de 6 células, devia se candidatar a Deputado ou outro cargo público, pois jura trabalhar incansávelmente por todo tempo possível sem eletricidade, alcançando até 6 horas de autonomia. Chega, quando tanto, a no máximo 3 horas, isso utilizando o perfil de "powersave". No momento tenho deixado a bateria descarregar até 10% antes de religar na tomada, pra tentar aumentar sua vida útil.
Falando em tomadas, essa veio com o formato novo, de 3 pinos que não encaixam em lugar nenhum. Felizmente consegui trocar o "rabixo" da tomada pelo do HP, que ainda é do formato antigo. E provavelmente precisarei usar os 2 quando estiver na rua, pois a conexão de tomadas tornou-se uma aventura agora: nunca se sabe que padrão irá encontrar.
Dessa vez optei por criar somente uma partição criptografada, o "/home" e fazer um link de "/root", "/tmp" e "/usr/local/tmp" (onde guardava alguns arquivos de trabalho) para esse mesmo diretório. Anteriormente todos já eram criptografados, mas isso exigia que eu entrasse com 3 senhas de partição durante o boot. Agora foi reduzido para somente 1 única vez. A recuperação de dados levou quase um dia, pois fiz a sincronização com o HD externo com "rsync" e extrai tudo com "tar". Tudo sobre partições XFS, que comecei a utilizar depois da sugestão do @eduardomacan, e que realmente funcionam muito bem para recovery rápido dos dados após um desligamento mal feito.
A análise é muito prematura, mas foi com o mesmo tempo que passei com o Dell, que devolvi. Com esse, vou ficar apesar do teclado.
Com certeza o tamanho e peso fizeram toda a diferença.
=-=-=-=-=
Powered by Blogilo
Usuários Debian ou Ubuntu, ou um de seus derivados, frequentemente encontram problema de chave ao realizar um "apt-get update", como abaixo:
root@musashi:DEBIAN# apt-get update
Get:1 http://dl.google.com stable Release.gpg [189 B]
Ign http://dl.google.com/linux/chrome/deb/ stable/main Translation-en
Hit http://ftp.de.debian.org squeeze Release.gpg
[... várias linhas suprimidas ...]
Hit ftp://debian.oregonstate.edu testing/main i386 Packages/DiffIndex
Hit ftp://debian.oregonstate.edu testing/contrib i386 Packages/DiffIndex
Hit ftp://debian.oregonstate.edu testing/non-free i386 Packages/DiffIndex
Fetched 5,197 B in 49s (104 B/s)
Reading package lists... Done
W: GPG error: http://deb.opera.com squeeze Release: The following signatures
couldn't be verified because the public key is not available: NO_PUBKEY F9A2F76A9D1A0061
W: GPG error: http://mirror.home-dn.net squeeze Release: The following signatures
couldn't be verified because the public key is not available: NO_PUBKEY 07DC563D1F41B907
W: GPG error: http://www.lamaresh.net squeeze Release: The following signatures
couldn't be verified because the public key is not available: NO_PUBKEY 905C75258D4B24D2
W: GPG error: http://mirror.home-dn.net testing Release: The following signatures
couldn't be verified because the public key is not available: NO_PUBKEY 07DC563D1F41B907
W: GPG error: http://www.debian-multimedia.org testing Release: The following signatures
couldn't be verified because the public key is not available: NO_PUBKEY 07DC563D1F41B907
W: GPG error: http://debian-multimedia.org squeeze Release: The following signatures
couldn't be verified because the public key is not available: NO_PUBKEY 07DC563D1F41B907
O erro de GPG mostrado é causado pela falta dessas chaves no sistema de controle do apt, o chamado chaveiro GPG (em geral localizado em "/etc/apt/trusted.gpg"). Essas chaves assinam os pacotes DEB instalados, garantido que os mesmos não foram modificados no repositório, evitando a instalação de "cavalos de tróia" e coisas de gênero (note que isso não garante a origem do pacote, por isso sempre use repositórios confiáveis).
Para corrigir, nada mais fácil que um scriptzinho, utilizando as chaves mostradas na saída de erro:
for key in F9A2F76A9D1A0061 07DC563D1F41B907 905C75258D4B24D2 \
07DC563D1F41B907 07DC563D1F41B907 07DC563D1F41B907
do
gpg --keyserver keyserver.ubuntu.com --recv $key | \
gpg --export --armor | apt-key add -
done
A saída será algo como:
gpg: requesting key 1F41B907 from hkp server keyserver.ubuntu.com
gpg: key 1F41B907: "Christian Marillat " not changed
gpg: Total number processed: 1
gpg: unchanged: 1
OK
para cada chave. O próximo "apt-get update" já não apresentará os mesmos problemas.
=-=-=-=-=
Powered by Blogilo
Update 2022-08-29: trocado subkeys.pgp.net por keyserver.ubuntu.com uma vez que o primeiro parece estar fora do ar.
Depois de uma rápida discussão no Twitter sobre treinamento em VoIP, lembrei que tinha esse documento perdido em algum lugar do meu HD. É uma explicaçã beeeeeeeeeeem superficial de VoIP e configuração básica do Asterisk.
Foi apresentado no Maratona HOWTO e também numa das oficinas Debian-SP.
