Translate

sexta-feira, 1 de janeiro de 2016

Repositórios de software Linux e gerenciador de pacotes Synaptic

Fig. 1 - Synaptic: 47 mil pacotes de software, classificados por status (instalados / não instalados no computador)

Os repositórios de software para Linux, disponíveis gratuitamente na rede mundial, — e o gerenciador de pacotes Synaptic, que agiliza a busca e a instalação, — me convenceram, faz mais de 10 anos, a não depender mais do Windows para trabalhar.

Não se trata de “ter” um sistema “meio esquisito” no computador “doméstico”. Trata-se de eliminar uma dependência, — para pesquisar, trabalhar, manter comunicação com o mundo, — que completaria 30 anos, daqui a 6 meses.

Porém, não sou “expert” (computação não é minha área). —Também não posso depender de “suporte externo” (nem deixar que cada mudança tecnológica afete a “produção”). — E já aprendi tanta coisa (para depois jogar fora), que não mergulho mais de cabeça em cada novidade, como se precisasse entender tudo.

Virei “leigo profissional”, — aprendo, hoje, o que preciso hoje; — o resto, aprendo quando precisar.

Isso afeta meu relacionamento com seres estranhos, tais como “linha de comandos”, scripts, Synaptic, Muon, Adept, Apper etc.

Portanto, não estranhe se fujo do esquema tradicional, de definições que não explicam nada, e soluções que são ótimas… para quem já entende do assunto. Nunca vi ninguém entender nada, lendo “definições”.

Digamos que “repositório” é onde “ficam” os softwares — com milhares de pessoas do mundo inteiro zelando pela confiabilidade deles; — e Synaptic é minha ferramenta preferida para encontrar, baixar e instalar tais softwares em distros da “família Debian” (Debian, Kubuntu, Linux Mint).

Os dois fazem parte de um sistema — bem maior — organizado para que  as coisas funcionem, o melhor possível. Se você decide instalar um “aplicativo”, poderá ser avisado de que ele depende de vários outros “pacotes”, que ainda não existem no seu computador. Você dá Ok, e o Synaptic instala o conjunto completo.

(Fica claro, portanto, que “pacote” não é, necessariamente, um “aplicativo”. — Pode ser um “driver”, uma “biblioteca” etc., — enfim, softwares que a gente não “clica para usar”, porém necessários ao funcionamento geral).

Fig. 1 - Acima, o Synaptic hoje cedo, listando 47.044 pacotes de software, — quase todos de “código aberto” (nada de “caixa preta”!), —  classificados conforme o status no computador: “Instalado”, “Instalado manualmente”, ou “Instalado obsoleto” (que já pode ser eliminado), e “Não instalado”.

Esta é a exibição mais usada, no dia-a-dia. Se você seleciona “Instalado”, na coluna lateral, a área principal listará apenas este subconjunto. Para saber se existe alguma coisa que pode ser eliminada, selecione “Instalado (local ou obsoleto)”. E assim por diante.

Antes de mais nada, clique em “Recarregar” (1º ícone da Barra de ferramentas), para receber a listagem mais recente dos “repositórios”. Se houver atualizações, surge mais uma categoria de status: “Instalado (atualizável)”. Basta clicar em “Marcar todas as atualizações”, e depois em “Aplicar”. Você será avisado dos pacotes a serem baixados (inclusive bibliotecas e complementos, chamados “dependências”), quantos bytes terá o download, quanto espaço vão ocupar no HD etc. Clicando “Marcar”, eles serão marcados para instalação / atualização.

Você pode procurar mais algumas coisas, e ir “marcando”.

No final, você clica em “Aplicar”, ele apresenta o resumo de tudo que será feito. Não sendo detectado nenhum problema, você dá Ok, começa o download, e depois a instalação.

Continue com seu trabalho. O Linux nunca exigiu que encerrasse tarefas ou fechasse janelas, enquanto instala ou atualiza alguma coisa. — Só no final, em alguns casos, será necessário fechar e reabrir um ou outro aplicativo (caso tenha instalado um complemento para ele), ou reiniciar o computador (caso tenha instalado um novo “núcleo” do sistema, o Kernel).

Voltemos à Fig. 1: A listagem exibida indica a “última versão” de cada pacote, e uma descrição curta. Ao selecionar um pacote, uma descrição mais completa é exibida no campo de baixo (com links para obter mais informações).

Retângulos preenchidos de verde assinalam os pacotes já instalados. Para esses, também indica a “versão instalada”.

No rodapé, o total de pacotes listados nessa janela, quantos estão instalados no computador, quantos estão “quebrados” (no computador), e quantos você já marcou para instalar / atualizar / “reinstalar” (corrigir), ou para remover.

Fig. 2 - Tela do Synaptic com os pacotes de software classificados por Seções (áreas de trabalho)

Fig. 2 - Embaixo do painel lateral, existem outras opões.

Se você escolhe “Seções”, poderá filtrar os pacotes de “Aplicativos de vídeo”, ou de “Banco de dados”, ou de “Ciência”, por exemplo — cada um, subdividido por repositórios de origem (Principal, Multiverse, Não livre, Universe), que veremos adiante.

Fig. 3 - Tela do Synaptic com os softwares classificados pelos “repositórios” de origem

Fig. 3 - Escolhendo listar os pacotes por “Origem”, podemos visualizar, na prática, o significado desta famosa definição, que encontramos por toda parte, quando procuramos descobrir o que são os tais “repositórios”:

  • Main - Programas “oficialmente suportados”.
  • Restricted - Programas “suportados”, cuja licença não é 100% livre (por exemplo, drivers Nvidia).
  • Universe - Programas mantidos pela comunidade, ou seja, que não são suportados oficialmente.
  • Multiverse - Programas que não são "livres" (por exemplo, Flashplugin, Fontes True Type).

Essa “definição” clássica não esclarece grandes coisas, para o iniciante (mesmo incluindo alguns exemplos, como fiz).

Na Fig. 3, você vê, com seus próprios olhos,  alguns dos tais programas “não livres” — e isso, para mim, ensina muito mais sobre “Multiverse”, do que 1.001 definições ou explicações detalhadas.

Percorrendo outros repositórios “Multiverse”, no Synaptic, é muito fácil transformar a “definição abstrata” em noção concreta das coisas, tal como são na “real”. Depois disso, você volta na “definição”, e entende o que ela “queria dizer”.

Começa a entender, também, que o Synaptic oferece muito mais do que a mera facilidade de encontrar, baixar e instalar software.

Fig. 34-36 - Proporção de softwares disponíveis nos diferentes repositórios

Na Fig. 34-36, por exemplo, incluí na listagem a coluna “Componente”, que usei para indexar a exibição. Depois, fiz 3 prints, que cortei e coloquei lado a lado, para montar uma comparação visual.

Primeiro, configurei o Synaptic para exibir a coluna “Componente”. Depois, cliquei nela, para ordenar todos os 47.044 pacotes, segundo a ordem alfabética dos repositórios de origem: “Main” (Principal), “Multiverse”, “Non-free”, “Restricted”, “Universe”.

Pelo indicador da barra de rolagem, fica evidente que os “pacotes” dos repositórios “Main” não chegam a 25% do total, enquanto os dos repositórios “Universe” são quase 75% da coleção disponível.

O acervo detectado pelo Synaptic em repositórios “Multiverse”, “Non-free” e “Restricted” não passa de uma tripinha, imprensada entre eles — embora possa ser muito chato viver sem alguns dos “pacotes” disponíveis nesse pequeno intervalo.

Fig. 33 - Pacotes instalados, ordenados por “Componente”

Na Fig. 33, foram listados apenas os pacotes instalados no computador, segundo a mesma ordem alfabética dos repositórios de origem, — e salta à vista que a proporção se inverte por completo: — A grande maioria dos pacotes instalados vêm dos repositórios principais (“Main”), e menos de 1/3 vêm de repositórios “Universe”.

Pouquíssimos vêm de repositórios “Multiverse”; apenas 1 é “Non-free”; e não existe nada de origem “Restricted”.

Ficamos, então, com 2 grandes repositórios:

  • Main - Programas “oficialmente suportados”.
  • Universe - Programas mantidos pela comunidade, ou seja, que não são suportados oficialmente.

Essa descrição dos repositórios “Universe” pode dar uma ideia um tanto injusta: — Um viveiro de bichos meio suspeitos, não muito confiáveis.

Não é bem isso!

A equipe que monta uma “Distribuição”, — como Ubuntu, Kubuntu, Mint etc., — tem em vista criar um “Live CD”, capaz de dar boot, “carregar” o sistema operacional, e ainda “rodar” uma série de aplicativos úteis ao maior número de usuários (Navegador, Office etc.), sem exigir instalação prévia no computador. O espaço é limitado. Até pouco tempo atrás, costumava caber tudo em 700 MB (CD). Agora, ultrapassa 1 Giga.

Tudo, dentro do “Live CD / DVD”, deve se encaixar e formar um conjunto consistente, amigável, atendendo  às limitações de qualquer iniciante. Facilitar a instalação no computador, se o novato gostar da experiência inicial. Depois disso, receber correções (pois sempre se descobrem falhas) e alguma atualização, durante 1 ano e meio, que é o período do “suporte”, — ou até 5 anos, no caso das edições “Long Term Support” (LTS).

Uma “Distribuição”, porém, pressupõe um conjunto bem maior de softwares (aplicativos, drivers, bibliotecas), para ser útil como sistema operacional. Daí, a necessidade de se criarem “repositórios”, — cujo conteúdo também deverá ser consistente, e receber alguma atualização, correções etc. durante o período do “suporte”.

Enquanto isso, a “comunidade”, — de onde vieram os pacotes reunidos na “distribuição”, — segue desenvolvendo normalmente. Seria impensável ficar parada, — como também seria impensável a equipe de cada “distribuição” tentar se responsabilizar pela compatibilidade de dezenas de milhares de pacotes que a “comunidade” continua desenvolvendo e atualizando, furiosamente.

Aquela “fatia” de softwares incluídos na Distribuição (“repositórios” inclusive) deve permanecer mais ou menos “estável”. O preço disso é uma perda de “novidade” (vitalidade), em benefício do usuário iniciante.

No caso das distribuições “Long Term Service” (LTS), que devem receber “suporte” durante 3 ou 5 anos, a perda de vitalidade é ainda maior, para maior durabilidade, — em benefício de quem tem um negócio, e não quer investir em mudanças, treinamento de pessoal etc., de 6 em 6 meses, a cada vez que surge uma nova Distribuição.


Boa parte dessa “estabilidade”, portanto, está embutida nos “repositórios” que vêm previamente definidos. Neles estará uma “fatia” mais segura, a ser mantida sob certo controle.

Mas, você pode configurar outros “repositórios” adicionais, — afinal, você não quer passar o resto da vida num berço com grades de proteção. Ou quer?

Fig. 9 - Repositórios configurados para o Synaptic buscar aplicativos e suas atualizações

Não lembro exatamente quais “repositórios” já vieram  configurados para a busca de atualizações e de novos pacotes. Minha primeira providência, em geral, é apenas “desmarcar” os repositórios de código-fonte (“src” = source), assim como o próprio CD/DVD de instalação (se já não foi desmarcado automaticamente, ao fim da instalação).

Onde se lê “trusty”, trata-se do Ubuntu / Kubuntu 14.04 (Abril 2014). Tudo que se vê aí, destina-se a essa “Distribuição” (também se diz “Distro”, para economizar língua). Somente o repositório do Google não é específico do “trusty”.

O repositório Google foi adicionado para a instalação do GoogleEarth. Lá estão descritos os procedimentos insanos que segui para isso (sempre pesquisando em várias fontes, e anotando tudo, para poder desfazer).

PPA =  “Personal Package Archives”. São repositórios individuais, de milhares de desenvolvedores, hospedados na plataforma Launchpad, mantida pela Canonical Ltd. para apoio ao trabalho da “comunidade”. Você adiciona PPAs, caso por caso, para experimentar pacotes específicos.

O PPA do Daniel Richter (no topo da lista) foi adicionado para instalar e manter atualizado o Grub-customizer, em 2012, quando descobri que o antigo Startup-manager deixou de existir no Ubuntu 12.04.

Em geral, o acréscimo funciona melhor por linhas de comando, pois não basta adicionar novos endereços pelo botão “Novo” (Fig. 9). Também é preciso obter a chave de segurança (Key).

Em cada caso, tenho usado linhas de comando indicados por sites que considere mais confiáveis. É comum encontrá-las num blog, depois em outro. Mesmo quando não dão o link da fonte, é muito fácil pesquisar pelo Google e chegar até a fonte original das linhas de comando, para conferir e aprender mais.

Ao pesquisar dicas & ajuda, fique sempre de olho na data das postagens. Dicas muito antigas podem já não funcionar. O Google permite estabelecer a época dos resultados que deseja encontrar. O “último ano” já é um bom limite, na maioria dos casos.

Fique atento, também, para a Distribuição a que se referem as dicas de linhas de comando. No caso do Kubuntu 14.04, o apelido é trusty. Muitas vezes, as postagens dizem para substituir o apelido usado lá, pelo apelido da sua Distro. Se você não se sentir seguro de fazer isso, pesquise até encontrar a dica mais correta e atual. E, antes de usá-la, não custa nada pesquisá-la até a origem (site da própria Distro, ou do repositório a ser adicionado).

O GetDeb foi acrescentado para instalação do BlueGriffon, que ainda não deu certo. Quando conseguir, conto como foi.

Fig. 7 - Histórico de pacotes instalados, atualizados e removidos pelo Synaptic

Os logs de instalação, remoção e atualização de pacotes, — por mês, dia e hora, — podem ser muito úteis (Fig. 7). Fico sabendo que só comecei a usar o Synaptic no dia 17 Setembro 2014, embora tenha instalado esse Kubuntu 4 dias antes.

É que o Kubuntu vem com outro programa, — chamado “Descobridor do Muon”, — que não me agrada. Para começo de conversa, esse “Descobridor” não consegue “descobrir” o Synaptic. Então, preciso usar o “descobridor” para instalar um outro programa, — chamado “Gerenciador de pacotes Muon”, — que finalmente é capaz de encontrar e instalar o Gerenciador de pacotes Synaptic. Acho que já deu para entender por que não gostei do “Descobridor”.

Se gostasse de usar “linha de comando”, — ou quisesse posar de bacana perante o pobre novato, — bastava dizer para abrir um “Terminal” (ãhn?), lascar um Sudo (ãããhhnnn???), e mandar essa ordem:

sudo apt-get install synaptic

Ninguém merece, né.

Fig. 8 - Pesquisando no Synaptic todas as vezes que instalei, desinstalei, atualizei o Unison

O histórico do Synaptic também pode ser muito útil para saber quando (e quantas vezes) cada pacote foi instalado, atualizado, reinstalado (para tentar “corrigir”) ou desinstalado. Basta pesquisar pelo nome.

Na Fig. 8, uma pesquisa localizou rapidamente minha “briga” para desmanchar uma antiga configuração do Unison.

Sabendo que a “briga” foi em 1º Dez. 2014, ficou fácil localizar no caderno as anotações, com todos os detalhes.

Esse caderno de anotações (por data) é muito prático, — principalmente quando algum problema te impede de acessar o HDD ou pesquisar na web.

• Colunas adicionais


Fig 99 - Seleção das colunas exibidas no Synaptic

Para obter os resultados da Fig. 33 e da Fig. 34-36 (montagem), o Synaptic foi configurado para exibir a coluna “Componente”.

O caminho para isso é:

Configurações → Preferências → aba Colunas e fontes

Além de marcar / desmarcar as colunas a serem exibidas, você também pode alterar a posição de cada uma. Basta selecionar qualquer uma delas e mover “para cima” / “para baixo”, pelos botões à direita.

•• Por que não Lojinha


Esse  texto foi originalmente escrito (1º Jan. 2016) em homenagem aos amigos que ainda usam e conhecem apenas Windows, — com seus softwares caríssimos (ou piratas de camelô), — só para dar um gostinho de como pode ser a vida, quando basta você abrir um Synaptic e obter dezenas de milhares de pacotes, diretamente dos respectivos desenvolvedores, sem sair de casa, nem ter de procurar vaga em estacionamento.

Só mais tarde vim a saber que o Synaptic foi criado pelo brasileiro Alfredo Kojima, e mantido pela equipe técnica do Mandriva Linux até o fim desta em 2011 (pt.wikipedia). Mais informações interessantes no Viva o Linux e na Softpedia News.

Como disse, jamais gostei do “Descobridor do Muon”, — um protótipo das atuais “Lojinhas” multicoloridas, — nem do “Gerenciador de pacotes do Muon”, bem mais parecido com o Synaptic.

Imagino que essa tendência esteja ligada a certos fenômenos:

  • Universalização dos dispositivos móveis, com telas pequenas, onde tudo deve ser simples.
  • Consequência expansão do público, — mais mais interessado em obter e usar aplicativos, do que em esmiuçar essas coisas.
  • Estímulo aos desenvolvedores de pequenos aplicativos, rapidamente disponibilizados.

Portanto, entendo que a “Lojinha” era um desenvolvimento necessário. — Apenas, sigo usando e me maravilhando com o computador de mesa (desktop), de preferência usando Linux, e um dia também BSD, quem sabe, só para “ver como é”. — Por enquanto, celular é mera utilidade. Nenhuma intenção de passar o dia explorando novidades nele, a curto prazo. Quem sabe, quando tiver um KDE ;-)

______
• Acrescentado em 30 Abr. 2016, usando a versão “0.83” do Synaptic, no Kubuntu 16.04.
•• Acrescentado em 16 Out. 2017.

— … ≠ • ≠ … —

Ferramentas &tc.


quarta-feira, 4 de novembro de 2015

Monitorando a temperatura da CPU no Linux e no Windows

Tela do CPUID HWMonitor (Windows) — com a temperatura normalizada, após a limpeza geral

Na onda de calor que antecedeu as primeiras chuvas dessa primavera no DF, o computador começou a apresentar comportamentos inesperados.

Por exemplo, reiniciar sozinho, de repente, — justo quando você está com meia dúzia de programas abertos ao mesmo tempo, — e, num piscar de olhos, as tarefas em andamento vão todas para o espaço.

Mas, também havia outros problemas, — que mal lembro, agora, — e, por conta deles, já vinha acelerando a migração de mais algumas tarefas, do Windows para os dois Linux (32-bit e 64-bit), que se mantinham bem mais estáveis.

O computador já vive aberto, bem à vista, em cima da mesa, — desde 2008 (ou antes), quando a ventoinha do antigo computador parou por completo, um belo dia, e ele quase foi para o espaço, — de modo que, agora (16 Out. 2015), bastou esticar a mão para confirmar que alguma coisa estava quente demais.

Reiniciei o computador, mantendo DEL apertado, — ir para a BIOS, — e verifiquei que a CPU estava com 68,5ºC. E logo evoluiu para 74,5ºC.

Desliguei por 1 ou 2 horas, e fui pensar no que fazer.

Não via jeito algum de retirar o cooler (ventoinha), — para limpar, — e depois reinstalar na CPU, sem desmontar a placa-mãe, e mais um monte de coisas. Mas, não podia desmontar o micro naquele momento.

Precisava, então, de mostradores de temperatura da CPU, — tanto no Windows quanto no Linux, — para atravessar mais alguns dias de trabalho.

Numa busca rápida na internet, encontrei várias sugestões de software para monitorar / exibir a temperatura da CPU, placa-mãe etc.

CPUID HWMonitor


Primeiro, baixei e instalei no Windows o CPUID HWMonitor. A versão free não oferece muitas opções, mas foi muito útil. De imediato, permitiu verificar que a temperatura da CPU estava em 60ºC, — ao realizar alguma tarefa rápida, foi a 71ºC, — e em seguida foi baixando para 67ºC.

Estava bom de encerrar o dia.

No dia seguinte, 17 Out., verifiquei que a CPU foi a 65ºC logo no carregamento do Windows. Depois, — deixado “em repouso”, — baixou até 55ºC.

Tratei de resolver o assunto mais urgente daquele dia, — uma resposta por e-mail, consultando vários documentos, — e o trabalho no Gmail não levou a CPU a mais do que 60ºC.

Comecei a trabalhar no Facebook, e a temperatura da CPU logo chegou a 98ºC.

O problema maior, portanto, estava no festival de javas, layers & outros bichos, comandado pelo FB, além da profusão de vídeos.

Primeira lição: — Não olhar os vídeos, no FB.

Testei o óbvio, — só para não deixar dúvida, — e o Youtube também levou a CPU a 98ºC, em poucos segundos.

Como não podia interromper vários trabalhos, tratei de conter os maus hábitos, fechar o excesso de abas e janelas, e me concentrar no fundamental.

De preferência, num dos dois Linux.

PS.: Naqueles primeiros 2 dias (16 e 17 Out.), estava olhando a temperatura “CPUTIM”, — “CPU Temperature Index”, — que é bem inferior à temperatura do núcleo “Core 0”. Isso pode ter gerado disparidade com outras leituras, dadas por outros programas. É possível que tenha influenciado, de alguma forma, na impressão de que o Windows provocava maior aquecimento. Esse “erro” prosseguiu em todas as demais leituras que fiz do HWMonitor, até o final daquele mês, — ou seja, até o final deste relato. Para mais esclarecimentos (ou mais confusão), recomendo este tópico de 2011 sobre a diferença entre “Tcase” e “Tjunction”; e também este outro tópico, explicitamente sobre “CPUTIM a 85ºC” [FRC, 4 Nov. 2015].

Tela do Psensor (Linux) — já com a temperatura normalizada, após a limpeza geral

Psensor


No final do mesmo dia 17 Out., instalei no Kubuntu (Linux) os “pacotes” lm-sensors e fancontrol. Em 18 Out. 2015, logo cedo, instalei no Linux os “pacotes” hddtemp e psensor. Esses 4 “pacotes” trouxeram, junto, mais algumas “bibliotecas” e “dependências”, — é o normal.

De todos esses, consegui me entender bem, desde logo, com o Psensor, — que configurei para carregar junto com o Kubuntu, — mas não sei quais, dos outros, ele utiliza. Na dúvida, deixei todos lá.

Psensor, lm-sensor, fancontrol e bibliotecas, obtidos no Linux através do Synaptic

De início, o gráfico ficava do lado direito, — inverti a posição, e ajustei a largura.

Bastou marcar a opção “CPU Temperature”, na caixa do lado direito, para o gráfico mostrar do lado esquerdo a evolução dos últimos 10 minutos, com atualização permanente.

Logo ficou evidente que os dois sistemas Linux (i386 e amd64) exigem bem menos esforço da CPU.

Usei o Wine (no Linux) para abrir um programa “pesado” do Windows e mandei executar suas 2 tarefas mais “pesadas”, uma após outra, com duração total de vários minutos. Ao final, a CPU não passou de 84ºC.

A essa altura, lembrei de um pequeno ventilador de mesa, — que já me ajudou em situações assim, desde os anos 90, e andava esquecido no meio das tralhas, — liguei e deixei apontado para a CPU. Logo a temperatura baixou e se estabilizou em 54~55ºC.

Mais tarde, no mesmo dia, voltei ao Facebook, — no Linux, usando apenas o Chrome, sem o ventilador de mesa, — e a temperatura da CPU foi de 74ºC a 84ºC. Tornei a ligar o ventilador, saí do Facebook, e rapidamente caiu para 58ºC. Mais algum tempo no navegando no Facebook, — agora, com o ventilador, — e foi a 76ºC.

PS.: Note que, ao adotar o Psensor no Linux, tudo indica que continuei olhando a temperatura “CPUTIM”, — “CPU Temperature Index”, — que é bem inferior à temperatura do núcleo “Core 0” [FRC, 4 Nov. 2015].

Tela do Speccy (Windows) — já com a temperatura normalizada, após a limpeza geral

Piriform Speccy


Um incômodo do CPUID HWMonitor é a quantidade de informações, todas em forma de texto e números, — o que dificulta olhar e localizar a temperatura da CPU, dezenas de vezes por dia.

No dia 19 Out., encontrei uma outra dica, baixei e instalei no Windows o Piriform Speccy.

Speccy (Windows): — Visualizar >> Opções >> System Tray

A versão free pode ser facilmente configurada para “minimizar” na forma de um mostrador na barra de tarefas, — e você escolhe qual item será mostrado ali, — bem ao lado do “relógio”.

Speccy minimizado: 45ºC, ao lado do relógio

Escolhi a exibição da temperatura da CPU.

Mais informações ao passar o mouse sobre o mostrador do Speccy

Passando o mouse por cima do mostrador, aparecem também as temperaturas da placa-mãe e dos dois HDs.

Speccy versus HWMonitor


Quando o Speccy oferece a opção “CPU 0”, dá a entender que não se trata do núcleo “Core 0”

Comparando com HWMonitor, descubro que Speccy indica, sim, a temperatura do núcleo “Core 0”

PS.: Note que, ao configurar o Speccy, — Visualizar >> Opções >> System Tray, — para mostrar na barra de tarefas a temperatura da “CPU”, o campo inferior exibe uma subopção “CPU 0 Average Temperature”. Porém, não afirma que se trata do primeiro núcleo (“Core 0”). As temperaturas do núcleo “Core 0” e do núcleo “Core 1” são opções claramente distintas. Mas, ao abri-lo, agora, lado a lado com o HWMonitor, descobri que a temperatura indicada pelo Speccy é, sim, a do “Core 0”. Só isso já invalida boa parte das observações em que me baseei para concluir que o Windows exigia mais da CPU [FRC, 4 Nov. 2015].

A caixa d’água pegou fogo


Logo pela manhã do dia 19 Out., o Inmet alertou para uma onda de calor em todo Centro-Oeste e outras regiões próximas.

Tempo abafado. Ar parado e quente.

À tarde, trabalhando no Windows, a CPU chegou perto dos 95ºC, por várias vezes, — mesmo abrindo apenas os programas estritamente necessários, um de cada vez.

Tratei de fazer só o mais urgente, — e desligar o computador nos intervalos, — em especial, das 15h às 19h (horário de verão desde a véspera).

Fui dormir cedo, não tinha jeito. — Quem sabe, de madrugada melhorava?

Voltei no dia 20 Out., às 3h da madrugada (4h pelo horário de verão), mas o trabalho contínuo no Facebook, — pelo Windows / Chrome, — levava a temperatura da CPU a 83ºC. Foi necessário ligar o ventilador de mesa.

Às 11h da manhã (horário de verão), o mesmo trabalho contínuo no Facebook, — pelo Linux / Chrome, — levava a temperatura da CPU a meros 60ºC.

No final da tarde, o mínimo do Windows, — sem fazer nada, — era de 61~62ºC. Abri uma página leve, no Chrome, e a temperatura da CPU pulou para 85ºC. Qualquer tentativa de trabalho, pulava para 95ºC. Ao abrir a barra lateral do Yoono, chegou a 100ºC por breve instante.

Esse padrão, — maior aquecimento nos Windows do que no Linux, — prosseguiu sem alteração nos dias 21 e 22.

No final da tarde do dia 22, a caixa d’água pegou fogo. Só desligando a energia, para não cozinhar debaixo do chuveiro.

À 0:40 h do dia 23 Out., finalmente pude retirar a ventoinha da CPU (cooler), só para constatar o óbvio — estava tão entupida de poeira, que não tinha nem por onde o vento passar. Suspeitei desde o princípio.

Agora, tinha 24 horas para reler Hardware: o guia definitivo (do Morimoto), desmontar o micro, levar a ventoinha ao borracheiro (para limpar com um jato de ar comprimido), conversar com alguns experts na feira, voltar e montar tudo de novo.

Mas isso, já é uma outra estória.

Qual a temperatura “normal”?


Eis uma questão, em que nunca tinha pensado.

Quando montei o computador, em 2009, — tudo novo, limpinho, zerado, — anotei todo tipo de parâmetros e configurações. Só não tive a ideia de anotar as temperaturas. Felizmente, fotografei.

Temperatura da CPU e rotação do cooler em 2009, ao montar o computador

Computador recém-montado, — tudo novo, cooler lubrificado de fábrica e sem desgaste, — ao dar a partida a CPU ficou em torno de 38,5ºC, e a ventoinha girava mansa, 1.318 RPM.

É claro que, ao carregar Windows (ou Linux), abrir vários programas, trabalhar várias horas, a coisa esquenta bem mais do que isso.

Num dos vários fóruns onde pesquisei, agora, vi gente afirmando até que 130ºC era normal, no computador dele. Ô loco. Tinha de estar zoando, só pode. No mesmo tópico, um participante mais sensato, — daqueles que mostram conhecimento de causa, — comentou que no computador dele a CPU raramente passa de 50ºC.

De fato, é o que tenho observado agora, após a limpeza do cooler e remontagem do micro, — com alguma variação para mais, já que não uso ventoinha de chassi (ele fica aberto), — mas também não tenho placa 3D, nem aceleradora, nem “envenenei” o clock, nem nada.

Temperatura da CPU e rotação do cooler, atualmente, após 2 horas de trabalho no Windows
PS.: Hoje, após 2 horas de trabalho no Windows (atualizando este relato), CPU em 44,5ºC e ventoinha em 3.000 RPM. Por que CPU Q-Fan Control “Disabled”? Sei que, em algum momento (não muito recente), algo me convenceu a desabilitar esse controle pelo hardware. Caso torne a reabilitá-lo, surge uma subopção “CPU Fan Profile”, com 3 alternativas: “Optimal”, “Silent Mode” e “Performance Mode” [FRC, 4 Nov. 2015].

Qual a temperatura máxima?


Gostaria de acreditar que o HWMonitor, o Speccy e o Psensor “sabem” qual seria o limite, e me avisariam do perigo, — mas, disso, ainda não tenho a menor certeza. Cada um tem suas características. Num deles (não lembro qual), você escolhe os limites para disparo de um alerta (o que não ajuda em nada, quando a gente mesmo não sabe).

A única certeza é que, — se a coisa ficar feia, — o próprio hardware desliga (ou reinicia), sem aviso.

Há um “diodo térmico”, para isso, — e a ele devo agradecer as vezes em que a tela ficou preta, no meio de vários trabalhos em andamento, e reiniciou o sistema. Evitou o pior.

Isso não aconteceu nenhuma vez, durante a semana de 16 a 22 Out. 2015, em que monitorei a temperatura pelo HWMonitor, o Speccy e o Psensor. O simples fato de estar consciente, observar a temperatura e aliviar o esforço da CPU, já foi suficiente para reduzir os riscos.

Quanto ao “limite razoável”, depois de pesquisar tudo que pude, naquela semana, — não me pergunte exatamente ondes, — cheguei à conclusão de que 95°C já é faixa de risco, ou quase.

Por via das dúvidas, sempre que chegava perto de 90ºC, já tratava de parar o trabalho, fechar alguns programas, abas e janelas. Só não assoprava para ajudar, porque queria evitar a fadiga.

PS.: A confirmação acabou surgindo depois de publicar este relato, quando comecei a conferir algumas dúvidas, e voltei a uma dica do Edivaldo Brito, que a traduziu do Make Tech Easier. É o que abordo no tópico logo abaixo, acrescentado agora [FRC, 4 Nov. 2015].

Lm-sensors X Psensor [4 Nov. 2015]


Procurando mais algumas alternativas para monitorar a temperatura da CPU nos sistemas Linux (i386 e amd64), acabei voltando ao conjunto “lm-sensors” (modo Terminal) e “psensor” (modo gráfico).

E descobri que o “lm-sensors” (modo Terminal) dá excelentes informações sobre temperaturas “altas” e “críticas”.

Comparação do Psensor (gráfico) com o Lm-sensor (terminal), no Kubuntu i386

Enquanto o “psensor” se limita a informar os máximos e mínimos observados num período recente, — com opção, até, de zerar esse “histórico”, — o “lm-sensors” informa “limites” mínimos e máximos (no caso da ventoinha do cooler), bem como as temperaturas consideradas “altas” e “críticas”.

Esses parâmetros são detectados na fase “preparatória” para rodar o “lm-sensors”.

1) Instalação:

sudo apt-get install lm-sensors

2) Configuração — detectar o hardware:

sudo sensors-detect

3) Executar de modo permanente, para acompanhamento dinâmico:

sudo watch sensors

Computador aberto, ventilador &tc.


Não se recomenda, pelo que vejo no 4º comentário de um tópico de 2011:

— “Aí já calham em usar o gabinete aberto (outra burrice, corta toda ventilação do sistema e toda circulação de ar quente-frio proveniente dos coolers), isto quando não tacam um ventilador assoprando de cara pro computador, hehe, utilidade 0”.

Portanto, crianças, não sigam meu (mau) exemplo.

Conky


Flagrante de altíssimas temperaturas pelo Conky, em sessão Live DVD de instalação do Manjaro

Cerca de 30 meses depois (já sem Windows), o Cooler da CPU tornou a acumular sujeira suficiente para perder eficiência, — e a crise foi deflagrada por um problema com Grub / os-prober, que gerava uso intensivo dos processadores durante dezenas de minutos, sem trégua.

Felizmente, desde meados de 2016 já tinha adotado o hábito de monitorar os indicadores pelo Conky, — até mesmo em sessões Live para instalação de distros Linux, — e ficar de olho em qualquer situação fora do normal.

— … ≠ • ≠ … —

Ferramentas &tc.


terça-feira, 15 de setembro de 2015

Conversão em massa de TIFF em JPEG

Instale o ImageMagick, disponível nos repositórios oficiais do Linux

1) Instale o ImageMagick, se ainda não tiver.

2) Abra o Dolphin, com o Terminal* embaixo, para agilizar.

3) Abra uma pasta lotada de arquivos TIFF

Tremenda besteira: em 2012 scanneava livros inteiros em TIFF

4) No Terminal (embaixo), cole o comando:

mogrify -format jpg *.tif

5) Uma vez criadas todas as cópias JPEG, delete os TIFF.

  • ver “Coluna Tipo para seleção rápida” (abaixo), para mais detalhes.

Em poucos segundos, surge um JPEG para cada TIFF

Explicando


ImageMagick - Vem com a instalação do Kubuntu, KDE Neon, Debian KDE etc.

Descrição exibida no instalador de pacotes Synaptic:

ImageMagick é uma suíte de software para criar, editar e compor imagens bitmap. Ele pode ler, converter e escrever imagens em vários formatos (mais de 100) incluindo DPX, EXR, GIF, JPEG, JPEG-2000, PDF, PhotoCD, PNG, Postscript, SVG e TIFF. Use o ImageMagick para traduzir, inverter, espelhar, rotacionar, redimensionar, cortar e transformar imagens, ajustar cores da imagem, aplicar vários efeitos especiais ou desenhar texto, linhas, polígonos, elipses e curvas Bézier. Todas as manipulações podem ser realizadas através de comandos shell bem como através de uma interfacegráfica X11 (display).

Observe o comando disparado a partir do Terminal:

mogrify -format jpg *.tif

Por princípio, mogrify faz todo tipo de edições em massa, tais como redimensionar, girar etc., porém substituindo os arquivos originais. — Use esta opção-padrão, se não sentir necessidade de conferir o resultado.

O parâmetro -format evita que os arquivos originais sejam substituídos. — Em vez disso, são criados novos arquivos no formato JPEG, para todos os arquivos existentes no formato TIFF.


Dolphin - Gerenciador de arquivos. Vem na instalação do Kubuntu, KDE Neon, Debian KDE etc.

Já faz um bom tempo que ativei a exibição do Terminal no rodapé do Dolphin. É muito prático, toda vez que você precisa disparar um comando dentro de uma pasta. O Terminal já está lá, posicionado em qualquer pasta que você vá.

* Controle >> Painéis >> Terminal (marcar para exibir), — ou simplesmente tecle “F4”.

1 - Comando “Mogrify” para converter todos os TIFF em JPEG, sem substituir os originais

Coluna Tipo para seleção rápida


No título das colunas, — “Nome”, “Tamanho”, “Data”, — clique com o botão direito e marque a caixa de “Tipo”.

Agrupe todos os arquivos TIFF (ordenados pela coluna Tipo) para selecionar rápido e sem falha

Você terá mais uma coluna, — “Tipo”. — Clique nela 1 ou 2 vezes, para exibir primeiro todos os TIFF, ou primeiro todos os JPEG.

Fica muito fácil selecionar todos os TIFF, — basta clicar no primeiro, depois Shift-clique no último.

Clique no título da coluna “Nome” para conferir: — passe o mouse sobre cada arquivo JPEG e visualize à direita

Torne a clicar no título da coluna “Nome”, — e deverá aparecer uma “zebra” de TIFF selecionado / JPEG não-selecionado.

Confira se algo não deu certo, ou se falta ou sobra alguma coisa. — Tudo ok?

Deletar todos os arquivos TIFF da pasta. — Vai ser rápido, não foi?

Aperte DEL, — e todos os TIFF desaparecem.

Esvazie a Lixeira, para ver o espaço liberado aumentar a olhos vistos

Lembre de “Esvaziar a Lixeira”, de vez em quando.

A cada operação dessas, a partição vai se esvaziando a olhos vistos.

28 Set. 2016 - Esta solução é ótima para lidar com pastas contendo grande número de arquivos, e foi adotada depois de procurar inutilmente por um “menu de contexto” (botão direito do mouse) que pudesse ser usado no Dolphin, ou outro gerenciador de arquivos.

Sabia que tal alternativa era possível, já tinha usado em outras épocas, e continuei procurando por vários meses, mas só agora foi encontrado o “caminho das pedras”, no Konqueror.

— … ≠ • ≠ … —

Ferramentas &tc.


domingo, 2 de agosto de 2015

Google Earth no Kubuntu amd64 (64-bit)

Google Earth no Linux Ubuntu 64-bit

Depois de instalar o Google Earth no Kubuntu i386 (32-bit), só faltava instalar também no Kubuntu amd64 (64-bit).

* Esses dois Linux são por segurança. Se conseguir inutilizar um deles, o outro estará à mão para trabalhar, e buscar solução. No momento, ambos são Kubuntu 14.04, com suporte até 2019 (LTS). O “principal” é amd64 (64-bit); e o “secundário” é i386 (32-bit). Ainda não vi diferença entre eles (exceto em casos específicos, como a instalação do Google Earth). Para não confundir, tive de instalar papéis de parede bem diferentes. Comecei a experiência pelo “secundário”, ontem, e só após tudo ok, tentei a mesma experiência no “principal”.

Misturar instruções para sistemas diferentes, — como  aqui e ali, — pode ser confuso para o leigo (que é quem mais precisa). Por isso, aproveitei as duas etapas dessa experiência para fazer registros separados do que tentei, do que consegui entender, e das dificuldades em cada caso.

Desse modo, as instruções ficam, também, separadas e claras (acho).

Note que as duas páginas usadas como referência têm datas bem diferentes.
A postagem no Guia do Ubuntu Perfeito parece ser de Out. 2010, e o debate nos comentários cessou em Abr. 2011. Os arquivos do blog terminam em Fev. 2012, fazendo supor que desde então não tenha recebido atualizações. É bom ter isso em mente, pois muita coisa pode ter mudado nesses 3 anos.
Já a postagem no Help Ubuntu é claramente datada: “última edição 2014-12-29 14:34:00 efectuada por gholmer”. Nessa data, o Kubuntu 14-04 já tinha 8 meses de uso generalizado no mundo inteiro.

Dependências & etc.

Tal como na instalação do Google Earth no Kubuntu i386 (32-bit), hoje segui o mesmo processo, de identificar as “dependências” contidas nas diversas linhas de comando “sudo apt-get install” (além de algum programa sugerido, como gdebi), e procurá-las através do Synaptic.

No caso do Kubuntu amd64 (64-bit), essa lista é bem mais extensa — e pude ver, no Synaptic, que quase tudo já estava instalado, provavelmente desde a última tentativa fracassada:


  • googleearth-package
  • mesa-utils
  • lsb-core
  • gdebi
  • ttf-mscorefonts-installer
  • ttf-dejavu
  • ttf-dejavu-core
  • ttf-dejavu-extra
  • ttf-bistream-vera
  • lib32nss-mdns
  • libfreeimage3
  • libc6-i386
  • libglib2.0-0:i386
  • libsm6:i386
  • libglu1-mesa:i386
  • libgl1-mesa-glx:i386
  • libxext6:i386
  • libxrender1:i386
  • libx11-6:i386
  • libfontconfig1:i386 lsb-core
  • multiarch-support


Método oficial

Há duas recomendações: — Uma delas, de usar no Kubuntu amd64 o pacote oficial do Google Earth para Debian / Ubuntu i386.

Acessei o site oficial do Google Earth e baixei os dois pacotes — i386 e amd64.

Download dos instaladores oficiais do Google Earth

Tentei primeiro o pacote para i386, clicando com o botão direito do mouse e mandando “abrir com” o instalador gdebi.

Numa segunda tentativa, mandei “abrir com” o instalador QApt.

Por fim, cliquei no pacote para Debian / Ubuntu amd64, e tentei só com o instalador QApt.

Nenhuma das três tentativas funcionou.

Com o instalador gdebi, deu erro evidente ao final do processo. Diz que concluiu, você clica em Ok, e surge a mensagem de que foi encerrado inesperadamente. Ao reiniciar o computador, ainda surge uma mensagem de que o sudo não foi fechado. Por isso, voltei ao instalador QApt, para tentar, tanto o pacote para i386, quanto o pacote para amd64.

Nos três casos, os instaladores declararam que todas as “dependências” estavam “satisfeitas”.

Nos três casos, ao iniciar o Google Earth apareceu mensagem de “Placa de vídeo não suportada”. Porém, em vez de mostrar um céu estrelado (sem a Terra), simplesmente abortava.

Nos três casos, verifiquei pelo Synaptic que o processo tinha acrescentado um (ou mais) repositórios Google / Linux / Earth / Deb (+ Webdesigner/Deb).

Em consequência, aparecia um arquivo googleearth-package na categoria “Novo no repositório” — ao mesmo tempo em que o googleearth-package já instalado ia para a categoria de “Instalado obsoleto”.

É um substituto “oficial” para o “googleearth-package” da comunidade Linux — e sua função não é “rodar”, nem “instalar”, como veremos adiante, em Método alternativo.

Só que o googleearth-package da comunidade Linux está na versão 7, enquanto o “Novo no repositório” do Google é versão 6.

Além disso, é muito bizarro, você instalar um Google Earth oficial que não funciona, como meio de obter um pacote a ser compilado, para depois ser instalado, em lugar do pacote oficial que acaba de baixar e instalar.

Não tinha orientações de como proceder. Teria de andar às cegas.

Nos três casos, utilizei o Synaptic para “Remoção completa” do Google Earth instalado.

Nos três casos, a “Remoção completa” eliminou apenas 1 pacote (programa), sem afetar as bibliotecas (“dependências”), instaladas antes.

Portanto, estava pronto para o plano B.

Método alternativo

O “método alternativo” consiste em disparar uma linha de comando no Terminal (tela preta), deflagrando o seguinte processo — em linguagem de leigo ignorantaço:

  1. Abrir uma lista de instruções a serem executadas, que incluem:
  2. Baixar o código binário mais novo, adequado ao computador, direto do Google;
  3. Verificar o hardware, as configurações, as bibliotecas presentes no computador;
  4. Combinar tudo isso num arquivo “instalável”, feito sob medida para seu computador, tal como ele é na data de hoje.

Depois, disparar uma segunda linha de comando, que “desempacota” e instala esta versão personalizada do Google Earth.

A primeira linha de comando gera o “pacote” instalável:

make-googleearth-package --force

Uma vez disparada, provocou um carnaval de letrinhas correndo na tela preta do Terminal, e terminou com a seguinte mensagem:

-----------------------------
Success!
You can now install the package with e.g:
  sudo dpkg -i googleearth_6.0.3.2197+1.1.0-1_amd64.deb
-----------------------------

Destaquei em negrito a segunda linha de comando, que desempacotará e instalará esse Google Earth personalizado para seu computador, tal como ele é hoje — hardware, sistema, configurações, bibliotecas etc.

Copiei, colei no Terminal e disparei esta segunda linha de comando, e o resultado foi este:

flavio@Kubuntu:~$ sudo dpkg -i googleearth_6.0.3.2197+1.1.0-1_amd64.deb
[sudo] password for flavio:
A seleccionar pacote anteriormente não seleccionado googleearth.
(Lendo banco de dados ... 569075 ficheiros e directórios actualmente instalados.)
Preparing to unpack googleearth_6.0.3.2197+1.1.0-1_amd64.deb ...
Unpacking googleearth (6.0.3.2197+1.1.0-1) ...
dpkg: problemas com dependências impedem a configuração de googleearth:
 googleearth depende de libcurl3:i386.
dpkg: error processing package googleearth (--install):
 problemas de dependência - deixando desconfigurado
Processing triggers for mime-support (3.54ubuntu1.1) ...
Processing triggers for shared-mime-info (1.2-0ubuntu3) ...
Unknown media type in type 'all/all'
Unknown media type in type 'all/allfiles'
Unknown media type in type 'uri/mms'
Unknown media type in type 'uri/mmst'
Unknown media type in type 'uri/mmsu'
Unknown media type in type 'uri/pnm'
Unknown media type in type 'uri/rtspt'
Unknown media type in type 'uri/rtspu'
Processing triggers for menu (2.1.46ubuntu1) ...
Processing triggers for gnome-menus (3.10.1-0ubuntu2) ...
Processing triggers for desktop-file-utils (0.22-1ubuntu1) ...
Erros foram encontrados durante o processamento de:
 googleearth
flavio@Kubuntu:~$ 

Assinalei em negrito alguns sinais inquietantes.

Rodando a segunda linha de comando no Terminal (esq.). À direita, o editor Kate para copiar tudo.

Tentei rodar o Google Earth, é claro, e o único resultado é que abortou em silêncio — sem mostrar nenhum aviso de “Placa de vídeo não suportada”.

Já é um avanço.

De volta às duas páginas de referência que venho seguindo desde ontem, notei uma terceira linha de comando, recomendada pelo Guia do Ubuntu Perfeito para verificar (e corrigir) problemas de “dependências”:

sudo apt-get install -y -f

Tratei de rodar essa terceira linha de comando no Terminal:

flavio@Kubuntu:~$ sudo apt-get install -y -f
[sudo] password for flavio:
Lendo listas de pacotes... Pronto
Construindo árvore de dependências    
Lendo informação de estado... Pronto
Corrigindo dependências... Pronto
Os pacotes extra a seguir serão instalados:
  libcurl3:i386 libidn11:i386 librtmp0:i386
Os NOVOS pacotes a seguir serão instalados:
  libcurl3:i386 libidn11:i386 librtmp0:i386
0 pacotes atualizados, 3 pacotes novos instalados, 0 a serem removidos e 0 não atualizados.
1 pacotes não totalmente instalados ou removidos.
É preciso baixar 324 kB de arquivos.                                    
Depois desta operação, 1.077 kB adicionais de espaço em disco serão usados.
Obter:1 http://br.archive.ubuntu.com/ubuntu/ trusty/main libidn11 i386 1.28-1ubuntu2 [92,3 kB]                                                      
Obter:2 http://br.archive.ubuntu.com/ubuntu/ trusty/main librtmp0 i386 2.4+20121230.gitdf6c518-1 [57,2 kB]                                          
Obter:3 http://br.archive.ubuntu.com/ubuntu/ trusty-updates/main libcurl3 i386 7.35.0-1ubuntu2.5 [174 kB]                                          
Baixados 324 kB em 1s (318 kB/s)                                        
A seleccionar pacote anteriormente não seleccionado libidn11:i386.      
(Lendo banco de dados ... 569908 ficheiros e directórios actualmente instalados.)                                                                  
Preparing to unpack .../libidn11_1.28-1ubuntu2_i386.deb ...              
Unpacking libidn11:i386 (1.28-1ubuntu2) ...                              
A seleccionar pacote anteriormente não seleccionado librtmp0:i386.      
Preparing to unpack .../librtmp0_2.4+20121230.gitdf6c518-1_i386.deb ...  
Unpacking librtmp0:i386 (2.4+20121230.gitdf6c518-1) ...                  
A seleccionar pacote anteriormente não seleccionado libcurl3:i386.      
Preparing to unpack .../libcurl3_7.35.0-1ubuntu2.5_i386.deb ...          
Unpacking libcurl3:i386 (7.35.0-1ubuntu2.5) ...                          
Configurando libidn11:i386 (1.28-1ubuntu2) ...
Configurando librtmp0:i386 (2.4+20121230.gitdf6c518-1) ...
Configurando libcurl3:i386 (7.35.0-1ubuntu2.5) ...
Configurando googleearth (6.0.3.2197+1.1.0-1) ...
Processing triggers for libc-bin (2.19-0ubuntu6.6) ...
Processing triggers for menu (2.1.46ubuntu1) ...
flavio@Kubuntu:~$ 

Pelo que se vê, foram detectadas mais 3 “dependências”, rapidamente instaladas.

Em seguida, detectou mais uma dependência, também rapidamente instalada.

E mais outra.

Por fim, deu uma arrumada geral, configurando isso e aquilo.

Chamei o Google Earth, para ver se funcionava.

Funcionou.

— … • … —

Kubuntu



Testes de trabalho em “Live USB”


sábado, 1 de agosto de 2015

Instalação do Google Earth no Kubuntu i386

Cadê a Terra que estava aqui.

O Google Earth é uma dessas coisas que mais tem dado trabalho, a cada mudança de um Linux para outro (Debian, Mint, Ubuntu etc.), ou migração para nova versão, ou simples reinstalação.

A última vez que consegui instalar o Google Earth com êxito, e com relativa facilidade, já faz algum tempo. Depois disso, nunca mais.

Reinstalei o Kubuntu 14.04 i386 (32-bit) como sistema “secundário” (estepe) e decidi tentar outra vez.

Método oficial

Download oficial do Google Earth

Primeiro passo, baixar o instalador oficial do próprio Google, para Debian / Ubuntu 32-bit.

Em seguida, abrir o arquivo google-earth-stable_current_i386.deb com o instalador de pacotes QApt.

Clicar no arquivo com o botão direito do mouse, e “Abrir com” o QApt.

Também poderia “Abrir com” o instalador gdebi, que instalei mais tarde (ver Método alternativo, abaixo).

Dependências identificadas pelo QApt

O QApt identificou uma longa lista de “dependências”, para o correto funcionamento do Google Earth no seio do povo.

Ok, instalar tudo que for necessário.

Completada a instalação “com sucesso”, vamos ao teste.

“Windows executou uma operação ilegal e será encerrado”… Não, péra…

“Placa de vídeo não suportada” !

Mentira.

Como disse, já consegui instalar o Google Earth neste mesmo computador, tempos atrás, com relativa facilidade — e usei por um bom tempo, até o dia em que precisei instalar outro Linux diferente, ou mais novo, ou experimental etc.

Portanto, nada de “placa de vídeo não suportada”.

Em todo caso, ao clicar “Ok”, você não é mandado para o espaço.

Ou é… mas no bom sentido.

O Google Earth continua abrindo normalmente — apenas, não aparece a “mãe Earth”, — só linhas do litoral e fronteiras, flutuando num vácuo belíssimo.

Chão de estrelas !

Navega-se muito bem. Consegui encontrar Campos do Jordão (SP), na maior moleza, ver o mapa de todas as ruas etc. Mas, não era bem isso, o que eu queria.

Faltava chão, se é que me entendem.

Desinstalei, usando o Synaptic.

Mais tarde (ver abaixo), pedi a remoção completa, para deixar o sistema tal como estava antes dessa tentativa.

Notei que a instalação oficial tinha acrescentado um repositório, o do Google Earth, de modo que atualizações seriam automaticamente detectadas pelo Synaptic — que costumo abrir todo dia, pela manhã, para checar atualizações.

Ao comandar a remoção completa, o repositório também foi eliminado, pois já não há o que atualizar.

Método alternativo

Procurando aqui e ali, encontrei duas páginas com vários comandos tipo “sudo apt-get install” que, em resumo, instalariam o seguinte:


  • googleearth-package
  • mesa-utils
  • lsb-core
  • gdebi
  • ttf-mscorefonts-installer
  • ttf-dejavu
  • ttf-dejavu-core
  • ttf-dejavu-extra
  • ttf-bistream-vera


O googleearth-package, mesa-utils, lsb-core e gdebi são presenças naturais nos repositórios de softwares Linux. Basta abrir o Synaptic, “Recarregar” (para atualizar informações), digitar esses nomes, e marcar para instalação os que ainda não estiverem instalados.

O lsb-core, por exemplo, estava entre as “dependências” detectadas pelo QApt na primeira tentativa.

Instalar qualquer coisa existente nos repositórios, usando o Synaptic, me deixa muito mais tranquilo do que copiar, colar e mandar executar linhas misteriosas de “apt-get install” no Terminal (tela preta) — onde o leigo às vezes se vê diante de demoras intermináveis, sem saber se as coisas estão andando como deviam, ou não. No Synaptic (gráfico), você sempre sabe a quantas anda, e qualquer “dependência” a mais, que for necessária, ele avisa antes, e você clica “Ok” sem susto.

As fontes “ttf” (Micro$oft) também se encontram nos repositórios do Linux, de modo que também mandei instalar, sem susto.

No final, ficou apenas uma instrução para colar no Terminal (tela preta) e disparar:

make-googleearth-package --force

O resultado é uma saraivada de linhas na tela preta, indicando que o Google foi conectado, está sendo feito o download do código binário “GoogleEarthLinux.bin”, entre outras coisas.

Em seguida, um arquivo de instruções realiza e grava uma série de configurações, levando em conta seu sistema, e os “pacotes” já instalados (“dependências”).

No caso específico do meu sistema, hardware etc., e na data de hoje, foi gerado então um arquivo instalável chamado “googleearth_6.0.3.2197+1.1.0-1_i386.deb”, que deve funcionar (teoricamente) para instalação no meu computador — mas não, necessariamente, em qualquer outro computador, nem em outra época do ano.

A operação terminou com estas linhas de mensagem:

-----------------------------
Success!
You can now install the package with e.g:
sudo dpkg -i googleearth_6.0.3.2197+1.1.0-1_i386.deb
-----------------------------

Copiei a última linha e colei no prompt de comando:

flavio@Kubuntu-II-i386:~$ sudo dpkg -i googleearth_6.0.3.2197+1.1.0-1_i386.deb
[sudo] password for flavio:

Digitada a senha, começaram aparecer mensagens de erro.

Eis algumas dessas mensagens de erro, esclarecendo que ainda faltava alguma coisa:

dpkg: problemas com dependências impedem a configuração de googleearth:
 googleearth depende de libfreeimage3; porém:
  Pacote libfreeimage3 não está instalado.

Voltei ao Synaptic, procurei o tal  libfreeimage3 e mandei instalar.

(Podia ter feito lá mesmo, no terminal, usando o “apt-get install”).

E tornei a mandar o mesmo comando:

flavio@Kubuntu-II-i386:~$ sudo dpkg -i googleearth_6.0.3.2197+1.1.0-1_i386.deb
(Lendo banco de dados ... 168181 ficheiros e directórios actualmente instalados.)
Preparing to unpack googleearth_6.0.3.2197+1.1.0-1_i386.deb ...
Unpacking googleearth (6.0.3.2197+1.1.0-1) over (6.0.3.2197+1.1.0-1) ...
Configurando googleearth (6.0.3.2197+1.1.0-1) ...
Processing triggers for mime-support (3.54ubuntu1.1) ...
Processing triggers for shared-mime-info (1.2-0ubuntu3) ...
Unknown media type in type 'all/all'
Unknown media type in type 'all/allfiles'
Unknown media type in type 'uri/mms'
Unknown media type in type 'uri/mmst'
Unknown media type in type 'uri/mmsu'
Unknown media type in type 'uri/pnm'
Unknown media type in type 'uri/rtspt'
Unknown media type in type 'uri/rtspu'
Processing triggers for desktop-file-utils (0.22-1ubuntu1) ...
flavio@Kubuntu-II-i386:~$ 

Novo teste, e…

Sem essa, de “Placa de vídeo não suportada”.


Funcionou.

Obs.: Para instalar o Google Earth no Ubuntu amd64 (64-bit), o caminho alternativo apresenta várias diferenças importantes, que  prefiro não incluir, para não complicar demais, mas você pode conferir aqui e ali.