Byteria: Kubuntu Xenial beta2: Discover e Spectacle

Uso da CPU pela animação inicial do Discover (“Muon”), com pequenos pulsos de uso da rede

O objetivo principal deste terceiro “teste de trabalho em Live USB” com o Kubuntu 16.04 Xenial beta2 LTS era investigar o funcionamento do Discover, — além de continuar explorando e aprendendo sobre o Xenial Xerus, que cedo ou tarde substituirá o sistema “principal” do computador (ainda Kubuntu 14.04 LTS). — Tudo isso, sem prejudicar as atividades cotidianas, pessoais e de trabalho.

A sessão Live USB foi iniciada às 13:09 de 9 Abr. 2016, — usando a daily build xenial-desktop-amd64.iso de 08-Apr-2016 05:38, baixada e gravada na véspera em Pendrive, por comando “dd”, — e prosseguiu até 2:30 de 12 Abr. 2016, totalizando 61h20min.

Gráfico da instalação do Synaptic pelo Discover

Descobrir o Discover

O Discover foi aberto às 13:34, — logo após as configurações mínimas de Fuso horário, Relógio, Spectacle (PrtScn), Teclado, Dolphin, Wallpaper, — e já com o Monitor do sistema (KSysguard) pronto para registrar o uso da CPU e da conexão (Network history).

Gráfico da instalação do Shutter pelo Discover

Apesar do Synaptic ficar disponível desde esse momento, vários softwares foram instalados pelo Discover, — sempre com esse monitoramento do uso da CPU e da Rede, — tanto nesse momento inicial, como depois, ao longo da sessão.

Gráfico da instalação do Gimp pelo Discover

Entre 13:34 ~ 13:46, foram instalados pelo Discover: Synaptic, Shutter, Gimp, KRuler, Psensor, Chromium (Relógio ainda marcando horário de Loncres). — No dia 9, às 22:39: Xsane. — E no dia 11, às 14:38: Qlix.

Gráfico (1) da instalação do Chromium pelo Discover

Gráfico (2) da instalação do Chromium pelo Discover

Afora isso, o Discover foi aberto várias outras vezes, — inclusive após ser removido e reinstalado, — sem nenhuma falha até o final da sessão.

Discover → Advanced → Configure software sources → Software restricted

Também foi o Discover que possibilitou marcar os repositórios “restricted” (“non-free”), — opção não encontrada no Synaptic, — para instalar ttf-mscorefonts.

Esse foco sobre o Discover foi motivado pelos problemas, — e dúvidas sem resposta, — na “Falha prévia” do segundo teste de trabalho em Live Kubuntu 16.04 Xenial beta LTS.

Outras épocas

Já faz alguns anos que procuro escapar do “Descobridor do Muon”, — tão logo ele apareça pela frente, — pelos motivos explicados ao escrever sobre o Synaptic.

Em resumo, o “Descobridor do Muon” não conseguia “descobrir” o Synaptic (por exemplo), e o jeito era instalar o “Gerenciador de pacotes do Muon” para, — só então, — conseguir instalar o Synaptic, e escapar de ambos.

Uso de CPU pela animação inicial do Discover, — leva até 1 minuto para conseguir digitar na busca, e parar

Acontece que isso foi em outra época, — o “Descobridor” era simples, leve, — e não causava nenhum mal.

Porém, nos últimos meses, 2 coisas, — pelo menos, — mudaram esse quadro:

1) Agora, o Discover encontra o Synaptic

2) Agora, o Discover exibe uma “animação” digna dos piores momentos da “febre dos sites em Flash”, — ocupa 50% da CPU, retardando em 1 minuto (ou mais), a resposta a qualquer clique, — e essa triste “animação” recomeça a todo momento, pois voltar ao início é quase a opção-padrão, dentro dele.

Muon ou Plasma

Em busca de mais informações, — para entender melhor, quem sabe, — desenhou-se o seguinte panorama:

O “Discover” do KDE Plasma não é mais “Muon”, — sem mantenedor há algum tempo, ou sem mantenedor com disponibilidade para acompanhar a evolução do KDE Plasma (ao que se diz aqui e ali), — obrigando a equipe do KDE a desenvolver uma alternativa.

Discover atende por “Muon”, no Menu, mas é o “plasma-discover”, — e não o “muon-discover”

Você abre o Menu, digita “Muon”, aparece o “Discover”, — mas não é o “muon-discover” que está instalado, — o que existe no Kubuntu 16.04 Xenial é o “plasma-discover”.

Ao procurar pela série Muon, no Synaptic, encontram-se pacotes transicionais para os equivalentes Plasma

E se você quiser voltar ao antigo “muon-discover”, não adianta procurar nos repositórios, — pois o que se encontra lá, com este nome, é um pacote de transição (“transitional package”), que leva… ao “plasma-discover”.

Instalar “muon” + “libmuon” permite voltar ao Muon Package Manager, eliminando os substitutos “plasma”

No entanto, pode-se voltar ao Muon Package Manager, — basta instalar simultaneamente “muon” + “libmuon”, — evidentemente usando outra ferramenta, pois o “plasma-discover” será necessariamente removido no processo.

Muon Package Manager instalado em Live USB Kubuntu 16.04 Xenial (não foi testado)

O Muon Package Manager foi instalado, mas não chegou a ser testado. Ao tentar fechá-lo (para fazer outras coisas), não houve jeito, nem mesmo pela Tabela de processos do Monitor do sistema (KSysguard). No entanto, o restante do sistema e demais aplicativos continuaram normais.

Para evitar um longo aprendizado fora dos objetivos imediatos, foi feito Log out / Log in, após fechar tudo mais, e em seguida desinstalado o Muon Package Manager, pela reinstalação do “plasma-discover” e “plasma-discover-updater”, — que automaticamente incluem os pacotes transicionais “muon-discover”, “muon-notifier” e “muon-updater”.

Qlix, instalado pelo Discover no dia 11: única solução encontrada para acessar o Nokia Lumia por cabo USB

No dia seguinte (11), o Discover (plasma-discover), reinstalado desse modo, foi utilizado para instalar o Qlix, com sucesso.

WindowsPhone, Digital Sony e Scanner via cabo USB

Qlix foi a única solução encontrada para acessar fotos (e demais arquivos) do WindowsPhone Nokia Lumia durante a sessão Live USB do Kubuntu 16.04 Xenial beta2.

No Kubuntu 14.04 LTS (HD), a conexão USB com o Nokia Lumia tem funcionado há bastante tempo, mas não há registro de “dificuldades” (nem de uma eventual “solução”).

Os registros encontrados são bem mais recentes, — datam da instalação do Linux Mint 17.3 Cinnamon, em Jan. 2016, — porém todas as soluções tentadas no Linux Mint, também não resultaram agora, no Kubuntu 16.04 Xenial em Live USB.

Essas tentativas incluíram: — mtp-tools, obexfs, obextool, gphoto2, gphotofs, gmtp, jmtpfs, mtpfs, gthumb, gnokii, — instalados (e ao final desinstalados) pelo Synaptic, uma vez que o Discover só encontrou obextool, gmtp, gthumb. É possível que tenha faltado alguma ferramenta, instalada para complementar outros programas (Dolphin, Konqueror, Krusader, Gwenview…) no Kubuntu 14.04, talvez até antes de ter Nokia Lumia.

Reconhecimento imediato da câmera digital Sony DSC-H2 conectada por cabo USB

Já a conexão com a câmera digital Sony DSC-H2 por cabo USB não apresentou dificuldade alguma, — bastou plugar e ligar, para ser reconhecida e exibida nos “locais” e nas “pastas” do Dolphin.

Teste do scanner com Xsane instalado pelo Discover desde o início da sessão Live USB Kubuntu 16.04 Xenia beta2

Foi feito também o teste do scanner USB, — com o Xsane instalado pelo Discover.

De quebra

Foi constatado que lm-sensors, hddtemp e fancontrol não são indispensáveis para o Psensor, — que trabalhou perfeitamente, desde a instalação pelo Discover, sem nenhum crash.

Aliás, não houve crash neste terceiro teste de trabalho em Live USB Kubuntu 16.04 Xenial beta2, — exceto um fechamento súbito do Dolphin (às 13:19 do dia 10), ao clicar com o botão direito do mouse em uma imagem TIFF, — sem perda de configuração, ao reabrir em seguida.

Isso, apesar de inúmeras mensagens de “Low disk space”, ao longo de todo o terceiro dia (11), a partir das 13:17. — Ou, melhor, uma notificação permanente no Painel, com alertas frequentes na área de trabalho.

Avisos de pouco espaço em “disco” (/home) ao longo do terceiro dia da sessão Live USB Kubuntu Xenial beta2

Esse aviso não se refere à “Memória”, em si, — houve só um momento em que chegou a ser usado 1,6 GiB dos 8,3 GiB Swap, caindo depois para 1,1 GiB, — mas ao “espaço” atribuído à “/home”. A certa altura, restavam menos de 160 MiB de “espaço” na “/home”. Esvaziar a Lixeira elevou o “espaço” restante para 190 MiB, o que ainda foi considerado muito pouco: — apenas 9% do “espaço” total atribuído a essa partição virtual.

Salvo melhor hipótese, isso talvez possa ser atribuído ao grande número de pacotes instalados ao longo da sessão Live USB Kubuntu Xenial beta2, — Gimp, Synaptic, Shutter, Kruler, Psensor, Chromium, fonts-arkpandora, ttf-mscorefonts-installer, muon + libmuon, pyRenamer, Xsane, mtp-tools, obexfs, obextool, gphoto2, gphotofs, gmtp, jmtpfs, mtpfs, gthumb, gnokii, Qlix, — mas a simples desinstalação de muitos desses pacotes (no dia 11) não voltou a aliviar a “/home”.

Apesar da notificação permanente e dos avisos frequentes, nenhum programa foi fechado ou poupado, para aliviar, — foram mantidos abertos (e usados o tempo todo): Chromium, Dolphin, Gimp, LibreOffice, System Monitor (KSysguard), Psensor, Gwenview, — e o trabalho prosseguiu sem nenhuma lentidão ou falha, por mais 15 horas.

Configuração de Pasta e Nome automático para salvar capturas de tela do Spectacle

Spectacle

A intenção inicial era utilizar o Shutter, — instalado logo no começo da sessão Live USB, — para a Captura de tela pela tecla PrtScn, salvando as imagens numa pasta específica, com nome automático no padrão YYYY-MM-DD_HH-MM-SS_Kxb2.png.

Porém, logo ficou claro que, no Kubuntu 16.04 Xenial Xerus, a atribuição da tecla PrtScn exige mais do que um simples “shutter -f”, — como acontece no Kubuntu 14.04 e no Linux Mint 17.3 Cinnamon.

Entre fazer um curso de KDE 5, — ou procurar outra solução mais imediata, — foi mais prático examinar melhor o Spectacle, e observar bem os atalhos existentes.

O Spectacle tem, sim, o recurso de salvar as imagens automaticamente, — apenas, fica escondida no atalho “Shift-Print”.

Bastou trocar esse atalho com o “Print”, — que, por padrão, apenas “chama” o Spectacle, exigindo uma opção e um “Salvar & sair”, — o que se torna muito chato, bem antes de chegar à 285ª captura de tela.

E o “Shift-Print” ficou para “apenas chamar” o Spectacle, — opção interessante para capturar Menus, por exemplo: — Você estabelece um “Delay” de 5 ou 15 segundos, clica em “Take new screenshot”, e tem tempo de sobra para abrir o menu e chegar ao sub-sub-menu que deseja documentar.

“Meta-Print” permaneceu atribuído a capturar e salvar automaticamente a janela ativa, — coisa pouco habitual, até o momento.

13 Out. 2016 - Ver também De volta ao Gnome-screenshot

pyRenamer

Mais uma vez, pyRenamer foi fundamental para enfileirar, — na ordem correta, — as primeiras capturas de tela, feitas até o momento em que o Fuso horário “pegou”.

Corrigindo os nomes dos primeiros screenshots pelo pyRenamer

Pelo formato de nome automático, bastou substituir o horário de Londres, — “_16-” pelo horário oficial do Brasil, — “_13-” nos primeiros screenshots.

O pyRenamer foi instalado através do Synaptic (embora encontrado também pelo Discover), assim como ttf-mscorefonts-installer, e também a substituição do “plasma-discover” pelo Muon Package Manager, e posterior des-substituição.

•• Falha prévia (II)

Também desta vez houve uma sessão prévia, — iniciada às 18:57 do dia 8 Abr. 2016, e abortada às 12:54 do dia 9, — falhada por 2 erros claramente humanos:

Tentativa de atribuir a tecla PrtScn ao Shutter. — Não funcionou, e não foi possível restabelecer a atribuição da tecla ao Spectacle, por não haver documentado a configuração original.

Erro na escolha do layout de Teclado (PT-PT!). — A causa do problema só foi “descoberta” depois de encerrada a sessão, examinando retroativamente as Capturas de tela.

•• Falha intermediária

Talvez fosse correto numerar esta “Falha prévia” como (III), uma vez que no primeiro teste de trabalho em Live Kubuntu Xenial (beta), também houve uma “sessão falhada”.

Porém, aquele primeiro teste de trabalho em Live Kubuntu Xenial (beta), não foi feito em sessão única, — mas, sim, em 3 sessões Live USB (3 dias consecutivos), — e a “falha” ocorreu na sessão intermediária.

Foi um primeiro “bate-cabeça” com o “Discover” (plasma), — e com o Ubuntu Software Center, — possivelmente também causado por falha humana.

Ponto provável de falha: — Talvez tenha clicado em algo que não o (esperado) “atualizar informações dos repositórios”? Em vez disso, teria clicado numa “atualização geral”? Vai saber! Não ficaram registros tão detalhados, que permitam certeza imediata, nem compensa obcecar-se numa investigação detalhista, e talvez inconclusiva.

As primeiras hipóteses eram muito vagas, em campos demasiadamente amplos, — inclusive “memória”, — e a providência imediata foi aprender mais sobre isso.

Só então (e por esse motivo), começou a boa prática de monitorar a “memória” (e o resto), —inicialmente pelo KInfocenter, pelo KSysguard, — depois também pelo Psensor.

Aliás, sem o Psensor, não arriscaria sessões de 30 ou 60 horas, sem primeiro substituir o cooler original pelo adquirido em Nov. 2015. E, mesmo assim, ainda teria dúvida em arriscar, “no escuro”. — “Ver” a real situação é o que transmite segurança.

No segundo teste de trabalho Live Kubuntu Xenial (beta2), voltou a ocorrer “bate-cabeça” com o “Discover” (plasma), mas, — sem documentar as Capturas de tela com o monitoramento pelo KSysguard, — persistiram dúvidas sobre o processo e o momento exato da instalação dos pacotes.

Fato é que o “plasma-discover” não “complica” a vida do “usuário comum” com indicações claras de que a instalação de pacotes tenha, de fato, terminado. Durante algum tempo, há indicações mais ou menos visíveis do andamento do processo. Depois, cessam, — é preciso passar o “mouse over” para ter alguma noção das fases de “download”, em seguida “instalando”, e por fim “Remover” (suposta indicação de “instalação concluída”). — E para casa uma dessas fases, é necessário retirar o “mouse over” e voltar, várias vezes, para ver se a situação já mudou.

Só neste terceiro teste de trabalho Live Kubuntu Xenial (beta2), finalmente, foi feito um acompanhamento mais exato, — pelo KSysguard, — dos processos de download e instalação de cada pacote.

Nada 100% “conclusivo”, — ao ponto de compreender a causa exata de cada falha anterior, — mas apenas o suficiente para afastar a maioria das dúvidas mais paranóicas, e para concluir que o “plasma-discover” pode ser usado. — Embora sem a menor intenção de usá-lo, exceto como ferramenta para instalar o Synaptic, o quanto antes, e nunca mais.

•• Conclusões

As únicas “falhas” realmente relevantes, nesses 3 testes de trabalho em Live USB Kubuntu Xenial (beta, beta2), foram, — ou podem ter sido, — de origem humana.

No entanto, — do ponto de vista de “segurança (para um leigo) em dispor de um sistema produtivo”, — a experiência desperta cautela quanto a outros aspectos, escaldados em sucessivas “migrações”, nos últimos 30 anos: — Apple OS → CP/M → MS-DOS → DR-DOS/Windows → Kurumin → Kubuntu, — passando pelo desaparecimento / perda de rumo de alguns softwares (Xerox Ventura Publisher, dBase), que em alguns casos ocasionaram perda total de trabalho acumulado (acervo digital), em outros casos exigiram horas excessivas para migração / conversão de arquivos, busca de alternativas (nem sempre satisfatórias), novo aprendizado (perda de produtividade) etc.

O “sistema principal”, — Kubuntu 14.04 LTS, — está operacional, satisfatório, plenamente produtivo, com um conjunto de aplicativos suportados em seus repositórios, e com as configurações acumuladas na “/home” ao longo de 4 anos. É o que comanda o backup diário, baixa as fotos do celular etc., — entre outras coisas, ainda não obtidas no “sistema alternativo” (Linux Mint 17.3 Cinnamon).

Isto sugere:

a) Instalar o novo Kubuntu 16.04 LTS Xenial Xerux, — sem urgência desatada, — inicialmente como “sistema alternativo”, até instalar e configurar todos os aplicativos necessários ao trabalho regular, conferir que ainda sejam os mesmos, ou, — se forem “substitutos”, — certificar que atendam às necessidades, aprender a usá-los etc.

b) Após Kubuntu 16.04 LTS Xenial Xerus tornar-se o “sistema principal”, rever o uso do “sistema alternativo”, — não mais como “teste” de outras distros (Debian, Linux Mint), — mas para acompanhamento ativo de novas versões intermediárias do próprio Kubuntu (16.10, 17.04, 17.10), pois fica evidente a inconveniência da longa acomodação a um LTS, seguida de súbita migração para outro LTS muito diferente.

Várias das “dificuldades” e estranhamentos experimentados agora, — num salto súbito do KDE 4.13.2 para 5.5.4, — já se teriam dissipado numa vivência sequencial do Kubuntu 14.10, 15.04, 15.10.

_______
Esta postagem foi inicialmente publicada às 23:58 de 9 Abr. 2016, com 1 imagem e alguns parágrafos, e desenvolvida até 1:15 de 12 Abr. 2016, com 17 imagens.
A sessão Live USB Kubuntu 16.04 Xenial beta2 (Daily Build 08-Apr-2016 05:38) foi carregada em 9 Abr. 2016, às 13:09, e prosseguiu até 2:30 de 12 Abr. 2016, totalizando 61h20min.
•• Reaberto em 16 Abr. 2016 para acréscimo dos tópicos “Falha prévia (II)” + “Falha intermediária” + “Conclusões”.

— … • … —

Byteria

Translate

sábado, 9 de abril de 2016

Kubuntu Xenial beta2: Discover e Spectacle