Translate

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.

quarta-feira, 24 de junho de 2015

Meu Wi-Fi parou de funcionar. E agora?

Após 2 dias sem conexão, o celular voltou a navegar.
E a solução era muito simples

Navegantes de celular já são 1 em cada 4 visitantes dos meus sites (25,24%), segundo o Analytics.

Usuários de computador de mesa (desktop) visitam, em média, 4,64 páginas. Usuários de tablet (ainda limitados a 3,78% dos visitantes) visitam 3,55 páginas, em média. Já os usuários de celulares percorrem apenas 2,63 páginas por visita, em média.

Pode ser devido a diferentes hábitos, faixas etárias, ou apenas porque navegam na rua, ou em movimento, ou em circunstâncias que não favorecem a navegação.

Ou, porque perdem mais tempo dando zoom in / zoom out, para ler os textos, ver as fotos, e tentar acertar em links microscópicos — afinal, o tempo de permanência é bem parecido: — 2min49, 2min22, 2min05, respectivamente.

Portanto, chegou a hora de adaptá-los a essa realidade, que daqui para frente só tende a crescer.

Trata-se de adotar tecnologias “responsivas”, ou seja, que consultam o dispositivo utilizado pelo navegante, e “respondem” exibindo o site da maneira mais adequada a cada caso.

Recomenda-se pensar, primeiro, no celular, ao formatar o lay-out do site, e só depois tratar da adaptação para telas maiores (“Mobile First”) — e nunca, o contrário.

Decidi começar a adaptação pelos blogs feitos no Blogger / Blogspot, pelo simples motivo de que alguns deles já se apresentam “naturalmente” adaptados para navegação em dispositivos móveis.

Afinal, no Blogger / Blogspot a “tecnologia” vai sendo atualizada constantemente, pelo próprio Google, bem como pelos voluntários que desenvolvem e disponibilizam “modelos” (ou “Templates”).

Se o “Template” que você adotou for antigo, e não resultar em uma boa apresentação no celular, apenas troque-o por outro “Template”, mais adequado.

Para não desmantelar tudo, enquanto procura, crie um outro blog no Blogger / Blogspot, e faça nele seus testes e experiências.

Uma forma de “povoar” rapidamente seu novo blog “experimental” é baixar um backup do blog “verdadeiro”, em seguida fazer upload desse backup para o blog de testes.

Meu Wi-Fi parou de funcionar!


Passei o dia 22 Jun. navegando no Byteria e no Mboabas, pelo celular, para observar e corrigir (no computador!) as postagens cuja exibição apresentava problemas — algumas fotos que se recusavam a caber na largura da telinha miúda, e outras que havia colocado “à direita” ou “à esquerda” do texto (bastou centralizá-las). Só tabelas, que foram dimensionadas para 600 pixels de largura, exigem algum ajuste mais trabalhoso.

À noite, saí para tentar ajudar uma amiga que estava enfrentando um problema com a NET Virtua, a uns 200 metros da minha casa, ou pouco mais. Tentei usar o celular para acessar a internet, lá, mas só consegui uma tela em branco, com a informação de que o site acessado (Byteria) deveria estar “enfrentando problemas” e não respondia.

Seria mais correto o MS-IE do celular (Nokia Lumia, sistema operacional Windows) informar que faltava conexão Wi-Fi — já que desabilitei o uso da conexão de dados da(s) operadora(s), para não me descontarem pagamento diário, mesmo com o celular sempre ao lado do Modem Wi-Fi.

O Blogger / Blogspot “sair do ar”, é coisa que até hoje nunca vi, “em todos esses anos nessa indústria vital”.

Problema, mesmo, é que — de volta para casa — o MS-IE do celular continuou apresentando tela em branco, e acusando todos os sites do mundo de estarem “enfrentando problemas”.

Nessa hora, todas as hipóteses mais tenebrosas passam pela cabeça. Desconfigurei alguma coisa? (Claro que não!). Fui invadido? Fui capturado? Clonado? Contaminado por vírus? A NET Virtua alterou meu IP? O Modem ficou bichado e preciso pedir outro?

Passei o dia 23 examinando as possibilidades, e checando as hipóteses que pareciam fazer algum sentido, mesmo que longínquo ou improvável. Nada resolvido.

A essa altura do campeonato, o melhor é tirar o assunto da cabeça, cuidar de outras coisas. Fiz isso.

Só então me ocorreu a ideia óbvia: — Pesquisar no Google “Meu Wifi parou de funcionar” — e pedir apenas resultados dos últimos 30 dias, para não perder tempo com problemas e soluções de outras épocas.

O primeiro resultado que parecia promissor e cliquei, do Olhar Digital, matou a charada.

Descreve uma lista bastante completa das possíveis causas do problema — mas tem o bom-senso de, logo de início, sugerir a solução mais simples e mais provável:

Desligue o Modem — e/ou o Roteador, se não for o próprio Modem — e torne a ligá-lo após 1 minuto.

O chamado “reset”, que nunca fez mal tentar, antes de mais nada.

Já tinha desligado e tornado a ligar o celular (sem resultado), mas aproveitei para desligar outra vez, em solidariedade ao Modem, e liguei novamente só após o Modem voltar a apresentar todas as luzes normalizadas.

Não sei se esse último reset do celular ajudou em alguma coisa. Provavelmente, não. Mas não me custou nada, nem poderia prejudicar.

Por via das dúvidas, também já tinha limpado o “histórico de navegação” do MS-IE Mobile (exceto senhas).

Mesmo assim, ficou o último endereço visitado (vfco.com.br), do qual ainda não tinha saído.

Tela branca, novamente!, aviso de que este site pode estar “enfrentando problemas” etc.

Recarregar — aquela seta em caracol à direita do endereço do site, embaixo, — e nada.

Então, apenas apaguei o endereço do site (vfco.com.br) na janelinha, embaixo, tornei a digitar o mesmo endereço (vfco.com.br)… e… carregou a página, normalmente!

(Já tinha feito isso, antes do “reset” do Modem Wi-Fi, sem resultado).

— … ≠ • ≠ … —

Ferramentas &tc.