domingo, 10 de julho de 2016

KDE "light" eliminando o PIM

Uso inicial de Memória RAM pelo Kubuntu 16.04, após a desinstalação dos componentes do PIM

A “suite” PIM, — Personal Information Management suite, — talvez seja o maior responsável pela fama de “pesado” que afasta do KDE a maioria dos usuários Linux.

O PIM é uma “suíte” de peso, — coisa para corporações, — embora muitos a usem em casa, e gostem imensamente.

Essa fama de “pesadão” é um espantalho para iniciantes em Linux, — quando procuram se informar por artigos na web, ou perguntam em algum fórum — “qual vocês recomendam?

Parâmetros das observações


Uso inicial de 0,82 GiB de Memória RAM, — e Baloo torrando CPU, — 1h10min após a instalação do Kubuntu 16.04

Com o PIM, o Kubuntu 16.04, — acabado de instalar, — já abria ocupando 0,82 GiB de Memória RAM, — ainda sem chamar o Dolphin, o Psensor, nem o Conky.

Após desinstalar os pacotes componentes do PIM, — em 16 Mai. 2016, — o Kubuntu 16.04 passou a abrir ocupando apenas 0,41 GiB de Memória RAM, com o Dolphin, Psensor e Conky.

Até hoje, — passados 2 meses, — o Kubuntu 16.04 mantém com notável precisão o uso inicial de 0,41 GiB, carregando por volta de 0min57seg ~ 1min05seg “uptime”, — que coincide bastante com o tempo cronometrado desde o “Enter” no menu do Grub.

  • Esses dados referem-se sempre a um Start / Restart da máquina, — pois o simples Logout / Login não reduz significativamente o uso anterior de Memória RAM.
  • Em todos os casos (exceto Cinnamon, no final), incluem o início automático do Dolphin, com 3 abas (no Kubuntu) a 5 abas (Debian, Neon), além do Conky, Psensor e KSysguard.
  • A maior parte dos “uptime” citados incluem alguma espera após o carregamento do desktop e do Conky, Psensor, KSysguard, Dolphin, até estabilizar o uso da Memória RAM.
  • Só a partir de 12 Jul. 2016, foram feitos alguns PrintScreen do momento exato em que o “desktop” é exibido (com estes aplicativos), — devido ao acionamento do KDE Spectacle, — porém essa pressa afeta o uso de Memória RAM, em alguns casos.
  • Todas as medidas de uso de Memória RAM são do KSysguard, — que “desconta” a parte que lhe toca. — O Conky indica, sempre, um uso maior de Memória RAM.

PIM - Personal Information Management suite


Processos do Akonadi ocupando Memória RAM para funções não-utilizadas pelo usuário

Se fosse oferecido à parte, — para instalação por decisão consciente, — talvez o PIM fosse mais conhecido.

Talvez houvesse mais artigos sobre “como usar”, — instalar, configurar, tirar o máximo proveito de seus recursos, — e até sobre “como remover”.

Tal como vem, — integrado (espalhado) no Kubuntu, — nunca me chamou atenção, desde 2009, e parece difícil até encontrar artigos sobre ele, — exceto generalidades um tanto superficiais, ou discussões entre pessoas que já o conhecem, por isso não carecem de apresentação.

Até onde é dado entender, começa (ou começava) por integrar uma série de coisas em torno de contatos (Kontact, KAddressBook) e cliente de email (Kmail), — anotações (Knotes, Kjots), calendário (Kalendar, KOrganizer), lembretes (KAlarm), relógio digital, feed de notícias (Akregator), cliente de publicação em blog (Blogilo), — além de algumas coisas como KTimeTracker, Kandy, KPilot, aparentemente abandonadas, a julgar por esse verbete de Ago. 2015.

Jamais utilizei nenhum desses aplicativos, ao longo de 7 anos, mas, — de um modo ou de outro, — ocuparam Memória RAM, esse tempo todo.

Uso de Memória RAM + “Memória compartilhada”, pelos processos Akonadi

Além da Memória RAM, cada processo também ocupa quantidade ainda maior de “Memória compartilhada”, — ente misterioso, que ainda não descobri onde mora, senão na RAM.

É espantoso, descobrir tanto gasto de Memória RAM com vários “processos” envolvendo Kmail (que nunca usei), datas de aniversário (que nunca armazenei), e assim por diante.

Em épocas anteriores, também ocupou o hit-parade um certo Nepomuk, — sigla de um ambicioso “Networked Environment for Personal, Ontology-based Management of Unified Knowledge”, — que parece ter sido ainda mais guloso de recursos, ao ponto de despertar protestos dos usuários.

Por trás disso tudo, nada menos que um banco de dados MySQL em funcionamento, — para administrar miríades de informações envolvidas em todos esses processos, nunca utilizados.

É como se um sistema instalasse um servidor de internet, — por padrão, — e as consequências fossem atribuídas ao “ambiente gráfico” (Desktop Environment), em si.

Uso e utilidade, com certeza, há de ter, — basta ver o grande número de comentários em torno de alguns problemas de upgrade / migração para o PIM (4.7) e, agora, o PIM 5.0. — Comentários que ajudam a formar uma ideia de sua estrutura e funcionamento, e deduzir suas funções.

Uma postagem sobre conceitos errôneos, — seguida de comentários / perguntas como “onde estão os meus dados?”, ou “onde estão meus emails?”, — pode ajudar a avaliar a relação Custo / Benefício, para cada usuário individual.

Enfim, um artigo denominado “PIM / Kmail não está morto”, — com alguns comentários, — ajuda a formar uma ideia da situação e perspectivas, no início deste ano.

Remoção do PIM


A simples desinstalação do akonadi-server já remove boa parte do PIM

O incentivo para desinstalar o PIM do Kubuntu 16.04 veio de um comentário de João M na comunidade Kubuntu, em 16 Mai. 2016, com link para um debate sobre o assunto em outro local.

Por precaução, porém, a remoção foi feita, tateando item por item, no Synaptic, — para ver as consequências da “desinstalação completa” de cada um, — e consultando algumas páginas sobre o Akonadi e KDE PIM Akonadi, para ter a certeza de não deixar escapar nada.

Teoricamente, não seria necessário desinstalar tudo isso, — basta alterar algumas configurações, para que determinados processos não sejam iniciados automaticamente ao carregar o Kubuntu, — e depois, ter o cuidado de nunca rodar os aplicativos citados nessas páginas sobre o PIM.

Causou certo receio, a referência ao widget Relógio digital, — não havia por que abrir mão dele, — porém não foi encontrada nele nenhuma configuração para exibir eventos ou alarmes, — e até hoje, não mostrou ter sofrido nada, com a eliminação do PIM.

A lista de pacotes a desinstalar, anotada ao longo do processo, — sempre tateando passo-a-passo, — serviu de guia, mais tarde, para desinstalar o PIM no Debian testing “Stretch” KDE, — e para descobrir que nada disso veio na instalação do KDE Neon User Edition:

  • kmail
  • kaddresbook
  • kontact
  • korganizer
  • knotes
  • kjots
  • kalarm
  • akonadi-server
  • baloo-utils

O Baloo, — independente de fazer parte ou não do PIM, — já estava na mira, desde quando ocupou a CPU para indexar milhões de arquivos existentes na antiga “/home”, logo após a instalação do Kubuntu 16.04.

Na época, apenas foi parado o “processo”, pelo KSysguard, e desabilitada a “Pesquisa de arquivos” (Desktop search) nas Configurações do sistema.

Agora, foi removido quase tudo do Baloo, que o Synaptic encontrou instalado.

Exceção aberta para o “balookf5”, cuja remoção faria um estrago no Kubuntu

Exceção foi o balookf5, — cuja remoção ameaçava causar um verdadeiro estrago no Kubuntu.

Desativação da carteira de senhas (KWallet)

Aproveitando o ensejo, também foi desativada a Carteira de senhas (KWallet), — que no Kubuntu 16.04 passou a exigir 4 digitações seguidas, a cada abertura do Chromium, a pretexto de uma “migração” (eternamente repetida), — e desde então, nunca fez falta.

Desativando alguns serviços de segundo plano, carregados na inicialização

Examinando as Configurações do sistema, mais alguns serviços também foram desmarcados.

Não parece haver lógica, p.ex., em carregar diariamente um alerta sobre mudanças de URL de pastas da rede, serviço de senhas para administração de rede etc. — Não há “rede”, por aqui. — Ou um monitoramento de emails enviados pelo Write (recurso tampouco utilizado).

Já vi sugestões de desativar o carregamento automático do Blue Tooth, — que também não é usado, — mas nunca se sabe quando aparecerá alguém que usa.


Debian testing “Stretch” KDE


Uso inicial de Memória RAM no Debian testing “Stretch” KDE (+múltiplos ambientes), ainda com o PIM

Na 2ª instalação do Debian testing “Stretch”, — onde coexistiram Xfce, Gnome, KDE, Cinnamon, MATE e LXDE, — ficou constatado não ser tão simples entender exatamente o quê acontece, por que acontece, e como obter resultados, em meio a tantos “ambientes gráficos”, — cada um com sua tropa de aplicativos favoritos, misturados em um Menu lotado de itens com nomes (quase) iguais, e às vezes chamados por engano.

O gerenciador de arquivos do Xfce funcionava muito bem no Xfce, — onde propagou a opção de “clique único” (single-click) para todo o sistema, — mas no KDE isto só acontecia com o Dolphin, — e em cada caso, o “outro” gerenciador fazia o oposto.

Em 1 ou 2 ambientes, a simples exibição do Psensor consumia CPU e ameaçava incendiar os núcleos, — embora bastasse minimizá-lo para tudo voltar ao normal.

Processos do PIM e do gnome-shell no Debian testing “Stretch” KDE (+múltiplos ambientes)

Enfim, — embora se rode apenas 1 “ambiente gráfico” de cada vez (“sessão”), — é complicado ter certeza de que ele carregará apenas seus próprios pacotes, e nenhum de outro “ambiente gráfico”, — quando mais não seja, para o controle de algumas variáveis do sistema, comuns a todos os “ambientes”, e que acabam influindo em todos eles.

A montagem automática de partições pelas “Configurações de sistema” do KDE, p.ex., não chegou a fazer efeito, — a montagem era feita manualmente, a título provisório.

Uso inicial de Memória RAM no Debian testing “Stretch” KDE (+múltiplos ambientes), sem o PIM

Com essas ressalvas, os registros indicaram uso inicial de 0,76 GiB aos 5min13seg (“uptime”), — no KDE, ainda com o PIM; — e de 0,55 GiB, aos 2min54seg “uptime”, no primeiro Restart após a desinstalação dos pacotes do PIM.

Porém, esses dados ainda carecem de um exame minucioso da sequência de Capturas de tela, — cruzando com anotações no Caderno e TXTs espalhados em várias pastas, — uma vez que não há mais como repetir experimentos e medições.

Uso inicial de 0,40 GiB de Memória RAM no Debian testing “Stretch” (exclusivamente) KDE, já sem o PIM

Na 3ª instalação do Debian testing “Stretch”, — exclusivamente KDE, — as configurações foram feitas em poucas horas, sem Restart, e não houve registro do uso inicial de Memória RAM ainda com o PIM.

O primeiro Restart, já sem o PIM, — e com o Conky, Psensor, KSysguard e Dolphin abrindo automaticamente (mas ainda sem efeito da montagem automática de partições pelas Configurações do KDE), — indica o uso inicial de 0,40 GiB de Memória RAM aos 2min51seg “uptime”.

Atualmente, esse tempo encontra-se estabilizado em torno de 0,35 ~ 0,37 GiB, “uptime” 2min36seg ~ 2min40seg, — que parece coincidir com o tempo desde o “Enter” no menu do Grub.

Em 12 Jul. 2016, finalmente foram solucionados 2 problemas que demoravam o carregamento, — reduzido para menos de 1 minuto, — e manteve-se o uso inicial de Memória RAM na faixa de 0,34 ~ 0,37 GiB.


KDE Neon User Edition


Uso inicial de Memória RAM pelo KDE Neon User Edition sem KDEWallet nem Pesquisa, logo após a instalação

(in)Felizmente, o KDE Neon não trouxe o PIM, ao ser instalado, — bastou desativar o KDEWallet e a Pesquisa de arquivos (Desktop search), — e o primeiro Restart resultou em uso inicial de 0,42 GiB aos 0min59seg.

O Conky ainda teve de ser acionado manualmente, — mas não alterou esse valor até 1min56seg “uptime”.

Atualmente, esse valor oscila em 0,38 ~ 0,39 GiB, medido por volta de 1min10seg “uptime”, quando já se estabilizou.

Linux Mint 18 KDE


No Linux Mint 18 “Sarah” KDE (Beta), instalado em 20 Ago. 2016, o PIM veio completo, porém não é carregado automaticamente, — com exceção do Baloo, — e por isso ainda não foi tomada qualquer providência para desinstalar os seus aplicativos.

O Baloo apenas foi “terminado”, — pela tabela de processos do Monitor do sistema (KSysguard), — e mais tarde foi desativada a “Pesquisa de arquivos”, para que não voltasse a ser carregado no início de cada sessão:

  • Configurações do sistema → Hardware → Dispositivos removíveis → Habilitar montagem automática → [_] Montar automaticamente no início da sessão

Kubuntu 14.04


Uso inicial de Memória RAM no antigo Kubuntu 14.04, ainda com o PIM

Antigas capturas de tela, de Março 2016, — ainda sem o Conky, — indicam que o Kubuntu 14.04 apresentava uso inicial de 0,80 GiB de Memória RAM, — com Dolphin, Psensor e KSysguard abrindo automaticamente e, naturalmente, o PIM.

Observa-se alguma variação, — de 0,78 até 0,84 GiB, — mas hoje é difícil identificar sob quais circunstâncias. — O mais frequente parece que era, mesmo, 0,80 GiB.

Mint 17.3 Cinnamon


Remoção do PIM instalado no Cinnamon pelo “plasma-widgets-addons”

Bastou 1 minuto.

Ao instalar um inocente widget de Clima (“Weather”), — só para “ver como é”, — o Cinnamon foi subitamente “invadido” por dezenas de pacotes do PIM.

O causador da encrenca foi o “plasma-widgets-addons”, — que trouxe consigo outros 64 pacotes.

Para removê-los, foram necessários 20 minutos, procurando de um por um, — pois a “remoção completa” de nenhum deles provocou a remoção em massa dos demais.

Aparentemente, o PIM não chegou a ser “disparado”, — não houve ocupação excepcional de Memória RAM, entre os dias 6 e 10 de Julho, nem apareceu entre os “processos”, no Monitor do sistema (gnome-system-monitor).


Distorções no uso da RAM


Disposição inicial das janelas ao carregar o Linux Mint 17.3 Cinnamon

É difícil avaliar o uso inicial de Memória RAM pela atual configuração do Linux Mint 17.3 Cinnamon, — que tem por base o Ubuntu 14.04, — e qualquer comparação é muito discutível.

Dispensado o gnome-screenshot, — que, naquela versão, usava dois-pontos (“:”) nos nomes-de-arquivo das capturas de tela, e só aceitava gravá-las na pasta “Imagens”, — restou apenas o Shutter, nos repositórios, como alternativa aceitável.

Acontece que, pelo modo como abre, — recuperando todas as Capturas de tela feitas desde o princípio dos tempos, — o Shutter distorce, de modo avassalador, o uso inicial de Memória RAM pelo Linux Mint 17.3 Cinnamon.

Uso inicial de Memória RAM no Linux Mint 17.3 Cinnamon, após o primeiro PrintScreen pelo Shutter

Atualmente, apresenta uso superior a 900 MiB, não raro 1,0 ~ 1,1 GiB, até ser feito o primeiro PrintScreen, — quando, então, a janela do Shutter se auto-oculta (para não ser capturada), e esse número desaba para alguma coisa na faixa de 450 ~ 550 MiB, — boa parte dos quais, ainda de responsabilidade do Shutter.

Afora isso, é muito comum o Shutter fugir de controle, — ocupando quase 100% da CPU, sem responder mais ao PrtScn, — sendo então necessário “matar” o “processo” e chamá-lo de novo, por comando manual.

Este é um dos motivos para a decisão de substituir o Linux Mint 17.3 Cinnamon pelo próximo Linux Mint 18 KDE, — mas há vários outros.

Comandos para iniciar aplicativos / montar partições em “Aplicativos de sessão”

Ainda não foi encontrado um recurso de “Salvar sessão” / “Restaurar sessão salva”, nem de “Restaurar sessão anterior”.

Por isso, quase tudo, que deve iniciar automaticamente, é chamado por comandos em “Aplicativos de sessão”, — desde a abertura do Shutter, do Conky, do Psensor, e do Monitor do sistema (gnome-system-monitor), até a montagem automática de partições adicionais, para que o trabalho possa começar rapidamente.

Recurso do Kwin, no KDE, que permite configurar as janelas de cada aplicativo

Resta, — a cada sessão, — fazer mais alguns ajustes, manualmente:

  • Mover cada janela para o local onde deve ficar.
  • Redimensionar o Psensor para o tamanho e formato desejados.
  • Abrir as pastas mais usadas, em novas abas do Dolphin, — por padrão, abre na “home”, embora você possa escolher outra pasta ou partição.

Faz falta um recurso que “lembre” o tamanho, formato e posição da janela do Psensor, — encontrado, p.ex., no Linux Mint 17.3 KDE.

Experiência


Em 13 Jul. 2016, foi feita uma experiência para tentar medir o uso inicial de Memória RAM pelo Linux Mint 17.3 Cinnamon, em condições mais próximas de sua configuração original, — abrindo o Nemo, em vez do Dolphin, e usando o gnome-screenshot, — portanto, sem carregar o Shutter ao iniciar a sessão.

Foi constatado uso de 325 MiB aos 51 segundos, — já incluído tempo para minimizar o Nemo e afastar o Monitor de sistema da frente do Conky, — estabilizando-se depois em 364 MiB por volta de 1min10seg “uptime”.

Aplicando um “delay” maior ao carregamento do Nemo, Psensor e Monitor do sistema, foi possível flagrar o momento exato de exibição do desktop, — com música, wallpaper e o Conky, — aos 37 segundos, ainda usando apenas 269 MiB de Memória RAM. — Mas por volta de 1min27seg, com esses 3 aplicativos, o uso de memória já se estabilizava em 363 MiB.

Deve-se levar em conta a abertura automática do mintUpdate, — que vem com um “delay” de 20 segundos, por default. — Isso deve ocorrer, portanto, em torno dos 57 segundos, ou pouco depois.

Arquivos do “gnome-screenshot”, — com string repetitiva, espaços, dois-pontos

Embora mais “leve”, — e mais “natural”, para o Cinnamon, — essa configuração experimental causou alguns incômodos, nas 24 horas seguintes.

Dezenas de Screenshots precisam ser buscados na pasta “/home/Imagens”, — renomeados, — e movidos para a pasta “F/000_print-screen”.

Renomeá-los envolve várias operações, no pyRenamer:

  • Substituir a string “Caputura de tela de ” por [nada].
  • Substituir [espaço em branco] por [sublinhado]
  • Substituir [dois-pontos] por [traço]
  • Substituir “.png” por “_M.png”

Fazer isso uma vez por semana, talvez não fosse tão incômodo, — mas fica chato, quando se precisa fazer isso várias vezes no mesmo dia.

  • 13 Out. 2016 - Foi encontrada, afinal, a solução para usar o gnome-screenshot, — versão mais nova, — sem nenhum desses 4 problemas. 

Painel “Informações” (à direita) agiliza localizar e renomear capturas de tela

Enfim, o Nemo apresenta grande demora para carregar pastas como “F/000_print-screen”, — com quase 2.000 arquivos, — que o Dolphin carrega e exibe quase instantaneamente.

Também é muito prático poder ver as imagens no painel “Informações”, à direita do Dolphin, — o que dispensa de abrir muitas delas, para saber do que se trata, e rapidamente identificar os grupos relativos a cada evento ou tarefa.

Por que KDE


Kurumin, — Debian + Knoppix + KDE, — foi a porta do GNU / Linux para uma geração inteira de “iniciantes”

O que é importante para uma parte dos usuários, pode não ter a menor relevância para muitos outros, — e, no GNU / Linux, são possíveis inúmeros “vice-versa”, combinando qualquer conjunto de características, para os mais variados tipos de usuários.

Uma das (muitas) coisas boas do GNU / Linux é a variedade de distribuições “principais”, — que se desdobram em centenas de “distros” mais ou menos “personalizadas”, para todos os gostos, — e tudo isso, com a opção de uma penca de “ambientes gráficos” (Desktop Environment) diferentes, — o que resulta em um número astronômico de combinações possíveis.

Centenas dessas combinações, você já encontra (quase) prontas, de modo que lhe reste muito pouco trabalho de configurar, para chegar ao que melhor atenda a seu gosto e necessidades.

Ou seja, “distribuições” que oferecem o máximo de “simplicidade” e de “facilidade”, — o que é bom para iniciantes, ou pessoas que simplesmente não queiram “perder tempo” personalizando o sistema.

Mas também encontra opções diametralmente opostas, — de máxima liberdade para configurar (quase) tudo, — sem necessidade de recorrer a mil comandos “trogloditas” (abaixo da “interface gráfica”).

O KDE volta-se nesta direção, — o mais amplo controle, e a mais ampla liberdade de configurar (quase) tudo, — tanto do próprio “ambiente gráfico” (Desktop Environment), quando do “sistema”.

Naturalmente, não ter muito controle (nem muitas opções), parece bem mais “simples”, — liberdade, às vezes, cansa os miolos, — mas não significa, necessariamente, que o KDE seja “difícil”, nem “complicado”.

De outro modo, seria inexplicável que o Kurumin, — com o KDE, — tenha sido a porta de entrada no GNU / Linux para uma geração inteira de “iniciantes”, no Brasil, — atraindo milhares de novos usuários “domésticos”, no curto espaço de tempo de 5 anos, entre 2003 e 2007.

Que o KDE também possa ser tão razoavelmente “leve”, — e por “default”, como no KDE Neon, produzido na própria fundação KDE e.V., — é a cereja no topo do sorvete.

_______
Relato inicialmente publicado às 10:46 de 10 Jul. 2016, e desenvolvido até 17 Jul. 2016, no Kubuntu, KDE Neon, Debian KDE e Linux Mint Cinnamon.

— … • … —

Kubuntu


sexta-feira, 8 de julho de 2016

Transição automática do Neon para KDE 5.9

KDE Neon 5.9.0 após atualização regular pelo Synaptic

O KDE Plasma 5.9 foi anunciado em 31 Jan. 2017, porém até 2 Fev. à 1:30 (3:30 UTC) ainda não estava nos repositórios do KDE Neon User Edition.

O KDE Neon só voltou a ser carregado em 4 Fev., — quando foram atualizados 185 pacotes, instalados 14 e removidos 3. — Nem tudo se relacionava ao KDE (caso do Kernel, também atualizado no Kubuntu 16.04 LTS).

Quadro comparativo - Até 4 Fev. 2017, KDE Neon era o único a incorporar o KDE 5.9

Certo “excesso de multi-boot”, — já há 8 sistemas Linux instalados “lado-a-lado” (não VM), — vem espaçando as atualizações (pois já não são carregados e atualizados todos os dias), e retardando as observações, levantamentos e relatos.

Nenhum grande desastre, — como se poderia imaginar, a partir de alguns relatos ou comentários na web, — mas a divergência de experiências é o “normal”, uma vez que cada usuário tem sua área e nível de conhecimentos, seus usos e aplicativos, hardware específico etc.

Aqui, as novas “falhas” percebidas, até o momento, — sem nenhum exame ou teste exaustivo, — ainda são mínimas:

  1. Os ícones do Chromium e do Konsole colocados no Painel (para lançamento rápido) foram substituídos por outro ícone. — A correção não leva 1 minuto.
  2. O campo de busca do GoogleEarth não aceita cedilha, — você tenta digitar “Luçon”, e só consegue “Luon”. — Ok, digite “Lucon”, que dá na mesma.

Acessar Tela de apresentação pela Temas da área de trabalho, — problema antigo

Permanecem problemas já relatados, — mas com acréscimo:

  • Inacessível a seção de Temas da área de trabalho, em Configurações do sistema, — problema que agora também afeta outro caminho para a seção “Tela de apresentação”. — Como isso raramente é usado, permanece válida a alternativa de entrar pelo Recovery mode → Resume, fazer as alterações desejadas, e reiniciar para carregar pelo modo normal.
  • Konqueror ainda sem o painel lateral (F9), sem conversão rápida de imagens (PNG→JPEG) e sem montagem de imagens ISO, — neste caso, basta Abrir com → Ark.

Agora, Tela de apresentação inalcançável também via Inicialização e desligamento

De um ponto de vista bastante pessoal, o KDE Neon User Edition continua o 3º melhor sistema para o trabalho, — logo abaixo do Kubuntu 16.04 LTS e do Linux Mint 18 KDE, — uma vez que o item mais requisitado (ver Quadro comparativo) é percorrer várias “Páginas” do Facebook, para acompanhar os acontecimentos e compartilhar informações, — já que, se depender do “Feed de notícias”, o mundo pode acabar, e só no dia seguinte os “algoritmos” acharem que aquilo talvez lhe interesse.

Naturalmente, o Quadro comparativo (acima) inclui apenas os itens cujo funcionamento (ainda) não foi obtido em todos os sistemas instalados por aqui.

Histórico das transições


 4 Fev. KDE 5.9.0
19 Jan. Frameworks 5.30
29 Dez. KDE 5.8.5
14 Dez. Frameworks 5.29
23 Nov. KDE 5.8.4
19 Nov. Frameworks 5.28
 2 Nov. KDE 5.8.3
19 Out. KDE 5.8.2
12 Out. KDE 5.8.1
10 Out. Frameworks 5.27
 4 Out. KDE 5.8.0
15 Set. KDE 5.7.5
13 Set. Frameworks 5.26
26 Ago. KDE 5.7.4
16 Ago. Frameworks 5.25
 4 Ago. KDE 5.7.3
22 Jul. KDE 5.7.2
13 Jul. KDE 5.7.1
12 Jul. Frameworks 5.24
 6 Jul. KDE 5.7.0
16 Jun. KDE 5.6.5
14 Jun. Frameworks 5.23

Na sequência, algumas transições anteriores, com observações que mereceram registro mais detalhado:

  • Transição para KDE 5.8
  • Transição para KDE 5.7

Transição para KDE 5.8


KDE Neon 5.7.5 became 5.8 after update by Synaptic, this morning

O KDE 5.7.95 foi anunciado pela KDE.org em 15 Set. 2016 como “Plasma 5.8 LTS Beta”.

No dia 4 Out. 2016, finalmente foi anunciado o Plasma 5.8 LTS no dot.kde.org, no The KDE Community; — e sua inclusão no KDE Neon 5.8.

“sudo apt update” → 106 packages to update

Na Quarta-feira, 5 Out. 2016, o “sudo apt update” indicou a existência de 106 pacotes atualizáveis.

Synaptic: 8 packages to install, 103 to update, 3 to remove

Aberto o Synaptic, a atualização automática indicou 8 pacotes novos para instalação, 103 para atualização e 3 pacotes para remoção.

Tela de Login: shutdown em 4 segundos

Abstraindo das novidades no anúncio oficial, — e do ponto de vista de mero usuário leigo, — foram observadas: — (a) mais algumas melhorias “práticas”; e — (b) um pequeno problema, que talvez se resolva amanhã ou depois.

Leave /session: shutdown em 10 segundos

a) Uma das melhorias práticas foi a brutal redução no tempo para desligar (shutdown), — agora, alguma coisa como 10 segundos a partir do diálogo de saída do KDE Neon, ou cerca de 4 segundos a partir da tela de Login, — contra a longa demora dos primeiros tempos (ver “Bela melhoria”, na “Transição para 5.7).

Carregamento completo por volta de 1min 4seg

O carregamento completo, — incluídos Conky, Psensor, KSysguard, Xsensors, Dolphin (6 pastas em abas) e Wallpaper, — manteve-se em 1min04seg uptime (confere com o tempo cronometrado desde o clique no Menu de inicialização).

b) O pequeno problema foi percebido, — por mero acaso, — nas “Configurações do sistema → Aparência → Tema da área de trabalho”.

Configurações do sistema → Aparência → Tema da área de trabalho: inacessível

Mero acaso, apenas porque o tamanho invulgar da data no Relógio despertou a curiosidade de rever como isso foi feito, — nada urgente ou crítico, — e não foi possível entrar em “Tema da área de trabalho”.

Carrega-se o painel lateral específico da seção, mas o “miolo” permanece preenchido com uma cópia da página inicial das Configurações do sistema (System settings).

Parece que não funciona, mas só parece. —Não esqueça de “descartar alterações”, ao sair

E o pior, é que essa “cópia” da página inicial funciona. — Clicando a esmo, aqui e ali, pode ter mudado as configurações, sem perceber.

Para sair dessa situação, basta teclar “Esc”, — ou clicar em “Todas as configurações” (All settings), — para voltar à página principal. — Se surgir um aviso de que há configurações ainda não aplicadas, não se assuste. Escolha “descartar”.

Dificuldade semelhante, — para chegar à subseção “Tela de apresentação” (KDM), — já foi observada em alguma “distribuição” Linux instalada (qual?), este ano, e após algum tempo se normalizou.

É possível que este problema seja anterior ao KDE 5.8, — pois já faz algum tempo que não era acessada esta seção das Configurações do sistema.

O mesmo problema se repete no Kubuntu 17.04 Zesty Zapus (development branch), instalado em 27 Out. 2016, — onde acabou sendo encontrado um jeito de “driblar” esse obstáculo, pelo menos para examinar o problema e procurar uma solução.

Foi constatado que, se passar passar pelo “Recovery mode, — mesmo sem fazer nada, por ali, — e em seguida “Resume” (retomar o Boot), a seção “Configurações do sistema → Aparência → Temas da área de trabalho” poderá ser acessada, e funcionará normalmente.

Trata-se de um assunto potencialmente extenso, — porém sem urgência, uma vez que essa configuração é de uso muito eventual. — Por isso, vem sendo deixado em segundo plano, até reunir mais indicações de rumo para pesquisar.


12 Out. 2016 → KDE 5.8.1

19 Out. 2016 → KDE 5.8.2

  2 Nov. 2016 → KDE 5.8.3

23 Nov. 2016 → KDE 5.8.4

Problemão



Tela “tty1” pedindo “Login”, depois de uma atualização do KDE Neon User Edition

25 Out. 2016
 - Problema muito mais gritante, — pois inviabiliza o carregamento “normal” do KDE Neon User Edition, — foi registrado a partir de uma atualização que substituiu “xserver-xorg-video-intel” por “xserver-xorg-video-intel-arbiter” + “xserver-xorg-video-intel-native-modesetting”, — entre outras coisas:

Commit Log for Tue Oct 25 15:43:07 2016

Removidos:

xserver-xorg-video-intel

Atualizados:

libc-bin (2.23-0ubuntu3) to 2.23-0ubuntu4
libc-dev-bin (2.23-0ubuntu3) to 2.23-0ubuntu4
libc6 (2.23-0ubuntu3) to 2.23-0ubuntu4
libc6-dbg (2.23-0ubuntu3) to 2.23-0ubuntu4
libc6-dev (2.23-0ubuntu3) to 2.23-0ubuntu4
libc6-i386 (2.23-0ubuntu3) to 2.23-0ubuntu4
libc6:i386 (2.23-0ubuntu3) to 2.23-0ubuntu4
libgrantlee-templates5 (5.1.0-1+16.04+build1) to 5.1.0-2+16.04+build2
libkfontinst5 (4:5.8.2-0neon+16.04+build38) to 4:5.8.2-0neon+16.04+build40
libkfontinstui5 (4:5.8.2-0neon+16.04+build38) to 4:5.8.2-0neon+16.04+build40
libmysqlclient20 (5.7.15-0ubuntu0.16.04.1) to 5.7.16-0ubuntu0.16.04.1
libphonon4 (4:4.8.3-0ubuntu3) to 4:4.9.0-4+16.04+build13
libphonon4qt5-4 (4:4.8.3-0ubuntu3) to 4:4.9.0-4+16.04+build13
libqca-qt5-2 (2.1.1-0ubuntu2) to 2.1.1-0.0neon+16.04+build15
libqca-qt5-2-plugins (2.1.1-0ubuntu2) to 2.1.1-0.0neon+16.04+build15
locales (2.23-0ubuntu3) to 2.23-0ubuntu4
multiarch-support (2.23-0ubuntu3) to 2.23-0ubuntu4
mysql-common (5.7.15-0ubuntu0.16.04.1) to 5.7.16-0ubuntu0.16.04.1
neon-desktop (4+p16.04+git20161019.1610) to 4+p16.04+git20161025.1536
phonon (4:4.8.3-0ubuntu3) to 4:4.9.0-4+16.04+build13
phonon-backend-gstreamer (4:4.8.2-0ubuntu2) to 4:4.9.0-1+16.04+build2
phonon-backend-gstreamer-common (4:4.8.2-0ubuntu2) to 4:4.9.0-1+16.04+build2
phonon-backend-vlc (0.8.2-1ubuntu3) to 0.9.0-1+16.04+build2
phonon4qt5-backend-vlc (0.8.2-1ubuntu3) to 0.9.0-1+16.04+build2
plasma-desktop (4:5.8.2-0neon+16.04+build38) to 4:5.8.2-0neon+16.04+build40
plasma-desktop-data (4:5.8.2-0neon+16.04+build38) to 4:5.8.2-0neon+16.04+build40

Instalados:

phonon4qt5 (4:4.9.0-4+16.04+build13)
xserver-xorg-video-intel-arbiter (0+p16.04+git20161025.1002)
xserver-xorg-video-intel-native-modesetting (0+p16.04+git20161025.1002)

Adicionar legenda

Desse dia em diante, o Boot sempre empacava na tela preta “tty1 / Login”, — e não adiantava pedir “startx”.

A pesquisa sobre o assunto prometia vastos conhecimentos no maravilhoso domínio dos drivers, placas, X, OpenGL, compositor Wayland e outras maravilhas das mais avançadas tecnologias, — mas o fato é que nesse computador existe apenas o velho e bom “onboard” Intel dos idos de 2009, — que nunca deu problema antes, desde o Kubuntu 8.04 até o 16.04 (base do KDE Neon).

Mais uma vez, o único caminho para carregar o “ambiente gráfico” era através do “Recovery mode → Resume”, — solução precária, possivelmente faltando carregar alguns “drivers”, apenas para examinar a situação.

Restabelecendo o antigo “xserver-xorg-video-intel” no KDE Neon User Edition, pelo Synaptic

A solução “definitiva” foi “remover completamente” os dois novos pacotes, — “xserver-xorg-video-intel-arbiter” + “xserver-xorg-video-intel-native-modesetting”, — e reinstalar o antigo “xserver-xorg-video-intel”.

Isso foi feito pelo Synaptic, — testando cada passo para ver as consequências. — Implicava em remover também o pacote “neon-desktop”.

Com isso, o KDE Neon User Edition voltou a carregar pelos caminhos normais do Grub, — com todos os drivers, — após 8 dias tentando encontrar outra solução.

Infelizmente, ficam alguns possíveis problemas, — apenas varridos para baixo do tapete, — e que talvez se manifestem em futuras atualizações.

— … • … —

Transição para KDE 5.7


KDE Neon 5.7 User Edition, após atualizações corriqueiras pelo Synaptic

A transição do KDE Neon User 5.6, — instalado em 31 Mai. 2016, — para o KDE Plasma 5.7 transcorreu naturalmente, como simples atualização diária, pelo Synaptic, na manhã de 6 Jul. 2016.

Atualização de 179 pacotes, instalação de 9 novos pacotes e remoção de 1 pacote antigo, pelo Synaptic

Poderia passar desapercebida, — e passou, — exceto pelo tamanho incomum da “atualização”, que mereceu um PrintScreen, para registro.

KDE 5.7 não tocou sinos nem soltou foguetes

Chamou atenção o fato de que as “atualizações” abrangiam nada menos do que 179 pacotes, além da instalação de 9 novos pacotes e a remoção de 1 pacote antigo.


Porém, em meio às mais diversas atividades diárias, passou batido o fato de haver ingressado em “uma nova era”, com a passagem do KDE 5.6 para o 5.7.

Só no final do dia seguinte, fazendo hora no Distrowatch, vim a saber do festejado lançamento do KDE 5.7, em 5 Jul., — com reflexo no lançamento do KDE Neon 5.7 User Edition, às 23h UTC do mesmo dia (20h em Brasília).

Até aí, haviam chamado atenção, — ao ponto de serem anotados, — 1 pequena falha (que não se repetiu mais), e 1 bela melhoria no tempo de carregamento e de encerramento do KDE Neon.

Pequena falha - Meia hora depois, — ao tentar um Restart, — o KDE Neon não abriu o diálogo de saída.

Para não perder tempo, foi aberto um Terminal e disparado o comando “reboot”.

No dia seguinte (7 Jul.), ao carregar o KDE Neon pela manhã, a primeira providência foi conferir esse detalhe. — O diálogo de saída tinha voltado a responder normalmente, ao ser chamado.

Nesse dia, o Synaptic apresentou mais 18 pacotes a serem atualizados, e mais 1 novo pacote a ser instalado.


Bela melhoria - Meia hora mais tarde, foi observado que a saída do KDE Neon não passou por aquela demora “interminável”, — superior a 1 minuto, numa tela azul clara muito bonita, — que o caracterizava desde antes da instalação, ainda nos primeiros testes em Live USB.

No início da tarde, foi observado que o carregamento também não foi demorado, como costumava ser, — a bonita tela azul clara foi rapidamente substituída pela continuação do processo.

Por motivos alheios ao caso, o KDE Neon foi carregado mais 2 vezes consecutivas, — sempre sem demora na bonita tela azul clara.

Apenas na terceira saída, houve demora na bonita tela azul clara, — ok, nem tudo que é bom dura para sempre.

Agora, — 8 Jul., às 14:15, — foi feito um teste, com o cronômetro na mão, para conferir o que está dito acima:

  • Tempo de encerramento: permanência de menos de 10 segundos na bonita tela azul clara.

  • Tempo de carregamento: permanência de menos de 15 segundos na bonita tela azul clara.

A bonita tela azul piscina, um mês depois

9 Ago. 2016 - De um modo geral, essa melhoria permanece, a maior parte das vezes, porém ocorrem momentos em que o encerramento do KDE Neon volta a passar por uma longa demora na bonita tela azul clara.

Apertar “Enter”, — depois de algum tempo, — costuma fazer com que desligue (ou reinicie) de imediato, — o que sugere uma possível “herança” das sessões “Live USB” e/ou de Instalação.

Seria este o momento, talvez, em que outras distribuições, — exceto KDE Neon, — emitem alguma mensagem, tipo, “Remova o CD da Bandeja / o Pendrive do slot, e aperte Enter para encerrar”.

Menor uso de Memória RAM


Uso inicial de Memória RAM no KDE Neon 5.7

Um exame retrospectivo das Capturas de tela indica que o “consumo” inicial de Memória RAM foi reduzido de 0,46 GiB para 0,38 GiB.

Naturalmente, este “consumo” não é um padrão universal, — é decorrência de algumas opções pessoais, em uma configuração bastante específica:


  • Sem o Baloo, — pela desativação da “Pesquisa de arquivos” (Desktop search).

  • Sem o KDEwallet, — pela desativação da “Carteira de senhas”.

  • Com abertura automática do Conky, Psensor, KSysguard e Dolphin (5 abas, minimizado) no início de cada sessão.

Considerando apenas as Capturas de tela já renomeadas, — inclusão da string “inicio”, para localização rápida, — o uso inicial de Memória RAM encontrava-se já bastante estabilizado no final de Junho, com as 5 abas do Dolphin exibindo as mesmas 5 pastas atuais, e sem oscilação significativa no número de arquivos em cada uma delas:

 1º Jun. = 0,71
 1º Jun. = 0,42
 1º Jun. = 0,46
 1º Jun. = 0,42
 1º Jun. = 0,45
 1º Jun. = 0,42
  3 Jun. = 0,41
  4 Jun. = 0,42
  4 Jun. = 0,44
  5 Jun. = 0,44
  5 Jun. = 0,43
  6 Jun. = 0,46
  6 Jun. = 0,47
  6 Jun. = 0,47
  6 Jun. = 0,45
  7 Jun. = 0,47
  7 Jun. = 0,45
  8 Jun. = 0,48
  9 Jun. = 0,47
13 Jun. = 0,47

26 Jun. = 0,46 GiB at uptime 1 min 10 seg
28 Jun. = 0,46 GiB at uptime 1 min 09 seg
29 Jun. = 0,46 GiB at uptime 1 min 06 seg
29 Jun. = 0,44 GiB at uptime 1 min 02 seg
   6 Jul. = 0,46 GiB at uptime 1 min 08 seg
   7 Jul. = 0,38 GiB at uptime 1 min 13 seg
   8 Jul. = 0,38 GiB at uptime 1 min 14 seg
   8 Jul. = 0,39 GiB at uptime 1 min 10 seg

A pequena diferença no 2º registro do último dia 29 pode ser atribuída a alguns segundos que ainda faltassem para a abertura de mais algum processo.

Depois disso, ainda havia uma pequena elevação, ao acionar o PrtScn (Spectacle), voltando em seguida a 0,46 GiB, enquanto outro aplicativo não fosse aberto.

P.S.: Registros posteriores, — em geral, por volta de 1min10seg a 1min30seg, já estabilizado:

10 Jul. = 0,47
10 Jul. = 0,37
10 Jul. = 0,39
10 Jul. = 0,38
12 Jul. = 0,39
12 Jul. = 0,38
13 Jul. = 0,39
14 Jul. = 0,40
17 Jul. = 0,38
18 Jul. = 0,40
19 Jul. = 0,37
19 Jul. = 0,38
22 Jul. = 0,45

Um pouco mais difícil de avaliar, é a eficiência geral em “devolver” memória, — que varia muito, de uma sessão para outra, — e afinal, não depende só do KDE, como do Debian em geral, do Ubuntu em particular, e dos mais diversos aplicativos, — além de se navegar (ou não) em alguns sites agressivos, como o Facebook.

Ou, não só de “devolver” memória, — já que, começando por um “consumo” menor, é natural que também termine em nível um pouco mais baixo.

As medidas referem-se ao momento em que são fechados os demais aplicativos, permanecendo apenas Conky, Psensor, KSysguard visíveis (para o PrtScn final) e o Dolphin minimizado (muitas vezes com mais do que as 5 abas, e em pastas diferentes das iniciais).

  5 Jun. = 0,72 GiB (Swap = 0,02 GiB) uptime 15h22min
  6 Jun. = 0,51 GiB (Swap = 0,00 GiB) uptime   0h22min
11 Jun. = 0,59 GiB (Swap = 0,01 GiB) uptime   9h29min
25 Jun. = 0,68 GiB (Swap = 0,05 GiB) uptime 12h01min
28 Jun. = 0,62 GiB (Swap = 0,00 GiB) uptime   0h10min
29 Jun. = 0,58 GiB (Swap = 0,00 GiB) uptime   1h42min
  8 Jul.  = 0,48 GiB (Swap = 0,00 GiB) uptime   3h46min

Um único registro após a transição para o KDE 5.7 ainda é muito pouco para garantir que tenha havido uma melhoria “permanente”, — foi uma sessão relativamente curta, com abertura apenas do Chromium, Gimp, Kate e Gwenview, — e não do LibreOffice, nem do Facebook, p.ex., — mas na comparação existem também algumas sessões de 22 minutos, e até de 10 minutos (provavelmente com abertura apenas do Synaptic, para a atualização diária).

“Processos” ocupando Memória RAM, após o encerramento dos aplicativos

Apesar dessa pouca duração (3h46min) e do baixo uso de Memória RAM (0,48 GiB) ao encerrar, havia 1 “processo” Chromium, p.ex., e nada menos que 121 “processos” Gwenview (embora apenas 4 ocupando Memória).

Registros posteriores:

  9 Jul. = 0,48 (Swap = 0,07 GiB) uptime 1d 0h 15min
10 Jul. = 0,43 (Swap = 0,00 GiB) uptime      1h 22min

Obs.: Pouco ou nenhum uso de Swap, parece tornar a medida mais consistente, — pois quando alguma “crise” obriga a um grande uso de Swap, é comum “esvaziar” o resultado final no uso de RAM, até o encerramento da sessão (com Restart), ou além dela (sem Restart).

De 5.7.2 para 5.7.3


Atualizações do KDE para 5.7.3, no início de Agosto

No dia 27 Jul. 2016, foi registrado que o KDE já estava em 5.7.2.

No dia 2 Ago. 2016, foi anunciado o “KDE Plasma 5.7.3, bugfix Release for August”.

No dia 4 Ago. 2016, o Synaptic apresentou uma extensa lista de atualizações, — nada menos que 118 pacotes, — e o KDE (do Neon) passou a 5.7.3.

___________
Publicado em 8 Jul. 2016 (KDE 5.7)
Atualizado em 4 Ago. 2016 (KDE 5.7.3)
Atualizado em 26 Set. 2016 (Resumo das atualizações até KDE 5.7.5 / Kernel 4.4.0-38)
Atualizado em 5 Out. 2016 (KDE 5.8)

— … ≠ • ≠ … —

Kubuntu & KDE


segunda-feira, 4 de julho de 2016

Linux Mint 17.3 KDE em Live USB

Linux Mint 17.3 KDE na 2ª sessão do atual teste de trabalho Live USB (Pendrive)

Este teste de trabalho em Live USB visava confirmar, — ou alterar, — a decisão de substituir o Cinnamon pelo KDE, ao migrar do Linux Mint 17.3 para o Linux Mint 18.

Na qualidade de leigo em “tecnologia”, tinha algum receio de que o Linux Mint, — cujo “ambiente” típico é o Cinnamon, como que “feitos um para o outro”, — não se adaptasse bem ao KDE, e vice-versa.

Dúvida superada.

Até onde foi possível avaliar, — apenas em Live USB, e com as limitações de mero usuário mortal, — a integração Mint / KDE não parece deixar nada a desejar.

Pelo contrário, — traz algumas boas surpresas, que não conhecia no antigo Kubuntu 14.04.

Enquanto o Mint 18 KDE não vem


Se a cronologia passada servir de parâmetro, falta um mês para o lançamento do Linux Mint 18 KDE.

  • Da liberação do Linux Mint 17.3 Cinnamon e MATE Beta (23 Nov. 2015) até a do Xfce e KDE Beta (26 Dez. 2015) passaram-se 33 dias.

  • Do lançamento do Linux Mint 17.3 Cinnamon e MATE (4 Dez. 2015) até o lançamento do Xfce e KDE (9 Jan. 2016) passaram-se 36 dias.

Extrapolando esses 33~36 dias a partir do recente lançamento do Linux Mint 18 Cinnamon (30 Jun. 2016), pode-se imaginar que o Linux Mint 18 KDE seja lançado nos primeiros dias de Agosto.

Porém, extrapolando 33~36 dias desde a versão Beta Cinnamon e Mate (9 Jun. 2016), pode-se ter esperança de que a Beta do Xfce e do KDE saia daqui a uma semana, ou pouco mais.

Decidido a substituir também o Cinnamon pelo KDE, — a partir do Linux Mint 18, — este prazo precisava ser usado para conhecer o KDE no Mint, de modo a confirmar (ou mudar) essa decisão.

Com isso, finalmente pude começar a distinguir o que é específico do Linux Mint, — do que é específico do Cinnamon.

Sessões Live USB


O teste de trabalho foi realizado em 3 sessões:

A 1ª sessão foi carregada no Sáb., 2 Jul. 2016, às 18:13, e se prolongou até 0:28 da Seg., 4 Jul. 2016, no total de 30h15min (pelo menos). — Deveria se prolongar, porém houve falta de energia durante a madrugada, e o computador amanheceu desligado. Foi necessário carregar nova sessão Live USB.

A 2ª sessão foi carregada na Seg., 4 Jul. 2016, às 9:45, e se prolongou até à 0:24 da Ter., 5 Jul. 2016, no total de 14h40min.

A 3ª sessão foi carregada na Qui., 7 Jul. 2016, às 14:02, e se prolongou até 1:32 da Sex., 8 Jul. 2016, no total de 11h30min.

Drive SSD, Nokia Lumia e Sony DSC-H2


Recorde de uso de Swap e CPU, ao abrir um diretório com milhares de subdiretórios no Dolphin

Foram conectados por cabo USB o celular e a câmera digital, para baixar fotos, — devidamente renomeadas pelo pyRenamer, — e excepcionalmente um SSD externo de 1 Terabyte.

Navegar pelo Dolphin entre os 230.000 arquivos do SSD externo, — sem lembrar de fechar o Chromium, Gimp, LibreOffice, — fez com que o uso de Memória Swap chegasse a 2,7 GiB.

Esse “recorde” foi atingido às 14:11, na Segunda-feira, ao tentar abrir um diretório com mais de 5 mil subdiretórios, — ignoro quantos no primeiro “nível”. — O sistema pareceu “travado”, mas foi só impressão. Depois de alguns minutos, as coisas voltaram a andar, ainda que um tanto lentas a princípio.

Nessa hora, a possibilidade de “ver” no KSysguard o que estava acontecendo, — uso de praticamente 100% da CPU, — foi muito útil para evitar o pânico. Mesmo no momento em que tudo parecia “travado”, a verdade é que muitas coisas estavam acontecendo. Inclusive, provavelmente, gravação de dados da Memória RAM no Swap.

O exame do SSD externo foi deixado para outra ocasião, — embora ainda conectado e aberto no Dolphin, — e a 2ª sessão Live USB prosseguiu normalmente, por mais 10 horas, com pequenas “instabilidades” no Chromium / Facebook, — e nenhum crash.

Às 15:19, o uso do Swap já havia caído para 2,0 GiB, — ainda com o SSD externo aberto no Dolphin; — às 16:08 caiu para 1,4 GiB, com o fechamento do LibreOffice; mas à 0:24 caiu apenas até 1,3 GiB, com o fechamento do Chromium.

Limpeza da listagem “Terabyte-Arquivos.txt”, no Mint Cinnamon (instalado)

Nos dias subsequentes, o SSD externo foi examinado a partir dos sistemas Linux instalados, — Mint 17.3 Cinnamon e Kubuntu 16.04, — usando comandos para documentar em TXT todos os arquivos existentes:

flavio@linux2:/media/flavio/Terabyte$ ls -l -R > Terabyte-Arquivos.txt

e a árvore completa, por meio desse comando verdadeiramente troglodita, encontrado pronto:

ls -R | grep ":$" | sed -e 's/:$//' -e 's/[^-][^\/]*\//--/g' -e 's/^/   /' -e 's/-/|/' > Terabyte-Arvore.txt

O Linux Mint 17.3 Cinnamon (instalado) não chegou a ser submetido a nenhum grande “esforço”, — exceto esses comandos, e a posterior eliminação (substituição) em massa de umas 350.000 ocorrências de strings, tipo “-rw------- 2 flavio flavio”, referentes às permissões, proprietário, grupo etc. dos arquivos, — inclusive no $RECYCLE.BIN, — listados em Terabyte-Arquivos.txt, que assim pôde ser reduzido de 23,5 MiB para 13,7 MiB, no gedit.

É sempre mais prático procurar nomes e siglas por CTRL-F em um arquivo TXT, — com direito às informações de tamanho e localização, — do que em um SSD inteiro.

Árvore de diretórios gerado para o arquivo “Terabyte-Arvore.txt” no Mint Cinnamon (instalado)

Nada disso exige tanto do sistema, como exigiria a exibição “gráfica” para navegar no Dolphin, — na base do “olhômetro”, muito ineficiente, — e mal chegou a elevar a temperatura da CPU a uns 58ºC, durante alguns minutos.

Cálculo do espaço e conteúdo de uma grande pasta pelo Dolphin

O esforço maior acabou ficando para o Kubuntu 16.04 (instalado), onde o Dolphin confirmou-se um tanto inadequado para lidar com grande número de diretórios e arquivos.

Deletando milhares de arquivos do diretório $RECYCLE.BIN, no Krusader

Por fim, foi usado o Krusader para deletar, — sem passar pela “lixeira”, — dois diretórios com um número descomunal de antigos softwares para MS-DOS e Windows; e mais de 6 mil arquivos “apagados”, que continuavam intactos no diretório $RECYCLE-BIN. Uma “limpeza” de cerca de 140 GiB em uns 20 minutos (18:56~19:17).

Tarefas que, feitas as contas, não eram mesmo para uma sessão Live USB, — embora pudesse ser feito, se instalasse o Krusader e adotasse de imediato todas essas “estratégias”.

Dados Exif instantâneos


“Preview” da foto do início da 1ª sessão Live USB do Linux Mint 17.3 KDE, com todos os dados Exif

Ao comentar em uma comunidade Mint a minha surpresa com vários recursos do Linux Mint 17.3 KDE, que nunca tinha visto no Kubuntu, no Debian KDE, nem no KDE Neon, — todos em versões mais recentes do que ele, — um amigo respondeu, com o entusiasmo que caracteriza os adeptos dessa “distribuição”: — «en cualquier versión de mint encontraras esos detalles y herramientas que no estan presentes en los escritorios originales eso es lo que diferencia a Linux Mint del resto».

É o caso, p.ex., do Dolphin 4.14.2, quando se passa o ponteiro do mouse sobre uma imagem original, — intocada por editor de imagens ou pelo “tratamento” automático recebido ao fazer upload em portais como Facebook, — e pula diante dos olhos um “preview” com todos os dados Exif da fotografia.

Parando todos os “processos” Akonadi pelo KSysguard

Detalhe importante: — Uma das primeiras providências, ao iniciar a sessão Live USB do Linux Mint 17.3 KDE, foi conferir que “Pesquisa de arquivos” (Desktop search) estava desabilitado, e encerrar (pelo KSysguard) todos os “processos” Akonadi, — recursos que já vi serem recomendados para 1.001 utilidades, inclusive lidar com dados Exif, mas que na prática até hoje ainda não mostraram serviço.

Como encontrar quem informe, em um órgão público, a data de uma foto específica?

Quando se tenta obter informações sobre alguns milhares de fotos originais, das mais diversas procedências, — e sabem os colaboradores o quanto pode ser chato um “editor” que vive fazendo perguntas, — esse tipo de recurso vale mais do que mil efeitos gráficos no “desktop”.

Isso, quando o colaborador é seu chapa, amigão. — Mas, e na “máquina governamental”, — federal, estadual ou municipal, p.ex.?

Não duvido que se possa obter esse recurso no Kubuntu, no Debian ou no KDE Neon, — talvez até com a maior facilidade do mundo, — mas o fato é que nunca encontrei qualquer dica sobre isso, após meses procurando, pesquisando, e instalando dúzias de plugins.

Nos dias 5 e 6, o Kubuntu, o Debian KDE e o KDE Neon voltaram a ser examinados, na vã esperança de que algo semelhante pudesse ser obtido, ali, no Dolphin.

Fotos copiadas (drag-and-drop) no Dolphin, com as datas e horas originais do celular

Também não é comum, ao baixar fotos da câmera digital ou do celular, por simples arrastar-e-soltar (cópia) pelo Dolphin, — não pelo DigiKam, Gwenview, gThumb etc., — os arquivos trazerem suas datas e horas originais.

No dia 1º Jul. 2016, p.ex., foram baixadas 828 fotos do celular pelo Nemo, no Mint Cinnamon, — e todos os 828 arquivos estão “datados” desse dia, às 13:44~13:45 (sim, o processo durou 1 minuto).

Download e gravação ISO → Pendrive


Gravação da ISO do Linux Mint KDE no Pendrive, por comando “cp”

Sáb., 2 Jul. 2016 - A imagem ISO “linuxmint-17.3-kde-64bit.iso” foi baixada por Torrent às 13:38~13:54; e gravada no Pendrive por comando “cp” às 18:03~18:08.

A sessão Live USB foi carregada por volta das 18:13 (Foto de celular).

A primeira providência foi configurar o Fuso horário (18:15), para dispor de Capturas de tela corretamente datados desde o início, já que o aplicativo KSnapshot só parece oferecer numeração sequencial dos prints, para automação dos nomes de arquivo, portanto sem registro “visível” da hora (Foto de celular).

18:17 – Fuso horário e KSnapshot.

Configuração básica do Dolphin (18:18~18:21).

18:19 – O Dolphin “agrupa” os arquivos, separando-os por números e letras 0-9, A, B, C etc. (Foto de celular).

A constatação foi feita logo após a montagem da partição “F”, — necessária para que o KSnapshot possa salvar as Capturas de tela no HD, — lembrando que, numa sessão “Live USB” a pasta “home” é volátil, meramente “virtual” (Memória RAM), e tudo que for gravado ali poderá desaparecer num piscar de olhos, caso ocorra um “pico” momentâneo da rede elétrica.

Instalados pelo Synaptic:

Sat Jul  2 18:47:35 2016

Upgraded:

libcurl3 (7.35.0-1ubuntu2.5) to 7.35.0-1ubuntu2.6

Installed:

chromium-browser (51.0.2704.79-0ubuntu0.14.04.1.1121)
chromium-browser-l10n (51.0.2704.79-0ubuntu0.14.04.1.1121)
chromium-codecs-ffmpeg-extra (51.0.2704.79-0ubuntu0.14.04.1.1121)
conky-all (1.9.0-4)
curl (7.35.0-1ubuntu2.6)
fancontrol (1:3.3.4-2ubuntu1)
hddtemp (0.3-beta15-52)
libaudclient2 (3.4.3-1)
libdee-1.0-4 (1.2.7+14.04.20140324-0ubuntu1)
libid3tag0 (0.15.1b-10ubuntu1)
libimlib2 (1.4.6-2)
liblua5.1-0 (5.1.5-5ubuntu0.1)
libunity-protocol-private0 (7.1.4+14.04.20140210-0ubuntu1)
libunity-scopes-json-def-desktop (7.1.4+14.04.20140210-0ubuntu1)
libunity9 (7.1.4+14.04.20140210-0ubuntu1)
libxmmsclient6 (0.8+dfsg-9)
psensor (0.8.0.3-1ubuntu3)
psensor-common (0.8.0.3-1ubuntu3)
pyrenamer (0.6.0-1.1)
python-gconf (2.28.1+dfsg-1ubuntu2)
python-hachoir-core (1.3.3-3)
python-hachoir-metadata (1.3.3-1)
python-hachoir-parser (1.3.4-1)
python-support (1.0.15)
ttf-mscorefonts-installer (3.4+nmu1ubuntu1)
update-notifier-common (0.154.1ubuntu1)

Obs.: Nenhum pacote instalado por comando “apt”:

mint@mint:~ > history
    1  sudo sensors-detect
    2  clear
    3  sudo watch sensors
    4  exit
    5  cat /proc/swaps
    6  lsblk -f
    7  history

18:41 – KSysguard indica Swap de 16,2 GiB.

Desativando o uso das partições de Swap pertencentes ao Debian testing “Stretch” (Linux3)

18:43 – Utilizado o KDE Partition Manager para desativar o uso de 2 das 8 partições Swap: “Swap3a” e “Swap3b”, pertencentes ao Debian testing “Stretch” (Foto de celular). O alerta veio da observação do KSysguard, indicando “16,2 GiB de Swap”. Ao que parece, nada havia sido gravado nessas partições, ainda. — P.S.: Infelizmente, na Seg., 4 Jul. 2016, ao ter de iniciar nova sessão (ver abaixo), esqueci esse detalhe. Ao longo do dia houve verdadeiro “abuso” do Live Mint KDE, com uso de mais de 2 GiB de Swap. Torcendo, agora, para que o Debian não apresente sequelas.

18:44 – KSysguard indica Swap de 12,2 GiB, porém de modo contraditório, — em outra parte, ele mesmo continua indicando 16,2 GiB (isso passou desapercebido até o dia seguinte).

Edição do arquivo “.conkyrc”, copiado do Debian

Copiado e editado o arquivo “.conkyrc” do Debian para colar na “home” do Live USB Linux Mint 17.3 KDE (18:53~18:57). — A padronização dos Rótulos (Label) das partições fez com que essa edição seja bastante simples e rápida.

19:15 – Aplicado Wallpaper.

19:17 – Um erro de edição do arquivo “.conkyrc” foi corrigido às 19:17.

19:20 – Conky, Psensor e KSysguard funcionando.

Ajuste das “propriedades da janela específica” do Psensor, no KWin: lembrar posição e tamanho

19:23 – Ajuste das “propriedades da janela específica” do Psensor, pelo KWin, para que, — ao reabrir (automaticamente, no início de cada sessão), — “lembre” a posição e o tamanho exato.

Isso é particularmente útil para lidar com o Psensor, rebelde até à sua própria configuração interna de “restaurar tamanho e posição”.

Menu de opções para o controle de janelas do KWin

Este conjunto de configurações do KWin, bastante amplo, é uma das inúmeras características do KDE que fazem muita falta no Cinnamon, p.ex., onde a janela do Psensor precisa ser ajustada manualmente, a cada início de sessão.

Intervalos do Psensor precisam ser ajustados de 2 para 1 segundo

19:30 – Comando “sudo watch sensors” para conferir (após o “sudo sensors-detect”). Terminal (Konsole) já parcialmente configurado. — Conky ok.

Há 2 pontos em que o intervalo do Psensor precisa ser ajustado, de 2 para 1 segundo, em Preferências → Grafo, e em Preferência → Sensores.

KSysguard segue dando informações contraditórias sobre o Swap disponível. — Só corrigiu após ser fechado e reaberto.

Menu em “cascata”: muito mais prático do que o Menu K original

19:43 – Menu K substituído pelo Menu “cascade”. — Embora no Mint 17.3 KDE não haja uma identificação, tudo indica tratar-se do “Homerun Kicker”.

20:03 – Conexão por cabo USB da câmera Sony DSC-H2 para baixar um vídeo e algumas fotos recentes (até 20:08).

20:08 – Aplicada configuração de “clique único” (single-click) no Dolphin, com reflexo nos demais diálogos KDE.

Desconectar com segurança o cabo USB da câmera digital Sony DSC

20:10 – Desconectar com segurança a câmera Sony DSC-H2.

20:14 – Vídeo no Dragon Player.

21:03 – Configuração do layout de Teclado (PT-BR) e acesso ao 3º nível.

Opções da conexão USB Nokia Lumia (WP8)

21:44 – Conexão por cabo USB do celular Nokia Lumia (WP8). Das 4 opções de “ação”, existem 2 opções “Open with file manager”. A primeira delas dá erro; a segunda funciona com perfeição.

21:48 – Baixadas as 19 fotos mais recentes.

21:49 – Não existe opção de “desmontar”, “ejetar” ou “desconectar com segurança” o Nokia Lumia, no menu de contexto do Dolphin. Restou puxar o cabo assim mesmo. Nenhum dano observado até o dia seguinte pela manhã.

Renomeando 856 fotos de celular com pyRenamer: intensa atividade de CPU

22:01 – Aberto pyRenamer para renomear 856 fotos para o padrão “YYYY-MM-DD_HH-MM-SS_NL.jpg”. — O mais demorado é o processamento ao clicar em “Preview” (22:04~22:06), com intensa atividade de CPU.

22:07 – Ao clicar em “Rename”, os 856 arquivos são renomeados num piscar de olhos.

Obs.: Ao passar o apontador do mouse sobre um arquivo ainda no celular, o Dolphin exibe uma prévia da foto, e nada mais. — Porém, depois de copiados os arquivos para o HD, ao passar o ponteiro do mouse sobre um arquivo, a prévia da imagem vem acompanhada dos dados Exif da foto.

23:00 – KSysguard ainda contraditório, com 2 valores diferentes de Swap.

Domingo, 3 Jul. 2016


8:40 – Percebido que KSysguard aponta 16,2 GiB de Swap, no local mais visível (e 12,2 GiB em local mais discreto). KDE Partition Manager confirma que as partições Swap3a e Swap3b. — do Debian, — não estão sendo usadas.

8:50 – Comandos “cat /proc/swaps” e “lsblk -f” confirmam que as partições Swap do Debian não estão sendo usadas.

8:56 – KSysguard é fechado e novamente aberto, — e finalmente passa a exibir o valor correto do Swap, nas 2 indicações.

9:19 – Aberto o Gimp (configuração original: janelas de ferramentas incorporadas na janela principal).

9:22 – Opções de salvar configurações personalizadas de ferramentas do Gimp.

9:23 – Personalizadas e salvadas as opções de ferramentas do Gimp.

9:53 – Mais um ajuste no Conky, para exibir “K/ home1” e “M/ home2”.

9:54 – Salvar “.conkyrc” não basta para fazer efeito. É necessário encerrar o Conky e chamar novamente.

9:56 – Encerrados vários “processos” Akonadi, pelo KSysguard. Nenhum efeito perceptível no uso da Memória RAM. Não encontrado qualquer processo claramente associado ao PIM — Personal Information Manager do KDE.

12:10 – Desabilitado KDEwallet. Confirmado que Akonadi não está rodando.

Seg., 4 Jul. 2016


Estado do sistema após 30 horas, fechando tudo exceto Conky, Psensor, KSysguard e Dolphin

O computador ficou ligado, mas pela manhã estava parado, embora com a energia ligada (LEDs da Mobo e do Monitor). Mais tarde, foi confirmado que faltou energia em algum momento da madrugada.

Prints desse dia começam no nº 100 (o último da véspera foi nº 89).

Refazendo os passos da véspera, na Segunda-feira

Anotações, com a cópia dos pacotes instalados na véspera pelo Synaptic, foram uma mão-na-roda para refazer essa parte rapidamente.

Prudência e canja de galinha


O KDE, — “ambiente gráfico” que prefiro cada vez mais, — era o único que ainda não conhecia no Linux Mint.

Já instalei o Linux Mint Xfce, em 2011; e o Linux Mint Cinnamon, em 2014 e 2016. Também já testei o Linux Mint MATE, há vários anos, ainda em “Live CD”; e este ano o Linux Mint Debian Edition (LMDE-2) MATE, em Live USB. Apenas o Linux Mint KDE, nunca havia testado nem instalado.

Talvez porque quisesse aproveitar cada iniciativa para conhecer 2 coelhos de uma tacada só, — Mint + Cinnamon, Mint + Xfce, Mint + MATE, — pois o KDE já conhecia no Kurumin, no Kubuntu e no Debian, as “distros” com as quais sempre consegui trabalhar melhor.

A recente instalação do Debian testing “Stretch” com todos os “ambientes gráficos”, — Xfce, Gnome, KDE, Cinnamon, MATE, LXDE, — me “curou” dessa curiosidade.

Em poucas horas, pude percorrer todos esses “ambientes gráficos”, dentro de uma mesma “distro”, — mais: dentro de uma mesma instalação, — e em poucos dias pude examiná-los e compará-los de modo sistemático, quanto ao que cada um permite ou não permite (excluídas as configurações só possíveis por comandos “trogloditas”).

E a conclusão é que, — embora cada um desses “ambientes gráficos” ofereça muitas qualidades e características, que ainda estou longe de conhecer, — é com o KDE que vou continuar trabalhando.

___________
Relato produzido e publicado durante o teste de trabalho em Live USB com Linux Mint 17.3 KDE, — cuja 1ª sessão começou no Sáb., 2 Jul. 2016; retomado em 2ª sessão na Seg., 4 Jul. 2016; e novamente retomado em 3ª sessão na Qui., 7 Jul. 2016.

— … ≠ • ≠ … —

Linux Mint



Kubuntu & KDE