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 (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.

• Registro dos pacotes do PIM desinstalados pelo Synaptic.

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.

• Registro dos pacotes do PIM desinstalados pelo Synaptic.

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).

• Registro dos pacotes do PIM desinstalados pelo Synaptic.

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

• KDE “light” eliminando o PIM
• Transição automática do KDE Neon 5.6 para 5.7
• Instalação do KDE Neon User Edition
• Google Earth no KDE Neon e Kubuntu 16.04
• Linux ficou sem Administrador. Que fazer?
• Particionamento de HDs para 4 Linux
• Live KDE Neon Plasma Wayland Dev Edition (Unstable)
• Baloo consumindo CPU no Kubuntu 16.04 LTS
• Instalação do Kubuntu 16.04 LTS em 34 minutos
• Teste do Kubuntu 16.04 LTS em Live USB
• 4º Teste em Live Kubuntu Xenial beta2: — OCR e Scanner USB
• 3º Teste em Live Kubuntu Xenial beta2: — Discover e Spectacle
• 2º Teste de trabalho no Kubuntu 16.04 Xenial beta2 em Live USB
• 1º Teste de trabalho no Kubuntu 16.04 Xenial beta em Live USB
• Google Earth no Kubuntu amd64 (64bit)
• Google Earth no Kubuntu i386 (32bit)
• Pacotes instalados no Kubuntu 14.04 ao ser substituído (24 Abr. 2016)
• Histórico de instalação de pacotes no Kubuntu 14.04 LTS (2014-2016)
• Instalação do Kubuntu 14.04 Desktop amd64 (LTS)
• Configurando o teclado no Kubuntu 14.04
• Testando o Ubuntu 14.04 LTS a partir do “Live DVD”
• Migrando do Kubuntu 12.04 para 14.04 num domingão
• Dual boot, GRUB, StartUpManager, Ubuntu 12.04, Grub-customizer
• Instalação do Kubuntu 12.04
• Configuração manual de partições para o Linux (e Windows, também!)

Atualização do KDE Neon para Plasma 5.11

Plasma 5.11 no KDE Neon User Edition

10 Out. 2017 - Ao ver as notícias da liberação de uma versão de teste do Plasma 5.11, carreguei os 2 sistemas que costumam atualizar primeiro o KDE, — Arch e Neon, — mas apenas os repositórios do KDE Neon já tinham essa atualização.

O apt-update indicou 97 pacotes atualizáveis, — o Synaptic incluiu mais 1 a ser instalado, — e em 5 minutos o Plasma 5.11 já estava em funcionamento (conexão “10 megas” = 1,3 MiB/s).

Depois disso, os repositórios “br.archive.ubuntu” começaram a dar erro. — No final da tarde, voltaram a responder e chegou para o KDE Neon uma atualização / correção de Kernel, — também aplicável ao Kubuntu 16.04 LTS.

No Arch, a atualização só ocorreu na tarde de Quarta-feira (11).

Surto de CPU e elevação de Temperatura com o novo formato das Configurações de sistema

Afora as novas funcionalidades descritas nas Notas de lançamento (Release notes), meu hardware acusou surto de CPU (86%), — e rápida elevação da temperatura (73°C), — todas as vezes que se abre o aplicativo Configurações do sistema (System settings) com o novo formato, chamado Barra lateral.

Comportamento semelhante ao do Plasma Discover, — que há mais de um ano veio substituir o antigo Muon Discover, — só que pior.

CPU e Temperatura normais com os antigos formatos das Configurações do sistema

No entanto, basta selecionar um dos 2 formatos tradicionais de exibição, — em Árvore (Tree) ou em Ícones, — que o uso de CPU despenca para 2% e a Temperatura abaixa de imediato.

Weather plasmoid, com dados do yr.no, — e a versão mixuruca existente até ontem

Uma bela surpresa, — talvez sem relação alguma com o Plasma 5.11, — foi a chegada do widget Weather em formato completo, e que até agora só havia encontrado no Kubuntu 16.04 LTS.

Não. Esse Widget deve ser adicionado, — já devia ter feito isso no KDE Neon, com certeza, — qualquer que seja a distro.

Weather plasmoid com dados do OpenWeatherMap

No Mint KDE e no KDE Neon, até ontem, só havia um widget muito pobre, — e assim continua, no Mint KDE, — mas no KDE Neon o widget tinha desaparecido, hoje cedo, antes do upgrade.

Depois do upgrade, procurei Weather para reinstalar, — e apareceu no formato completo, com direito a 2 fontes de dados.

tty1, Login, startx

Boot do KDE Neon, — após upgrade do Plasma 5.11.0, — com escala em tty1 + Login + startx

Problema bem mais chato foi a falha em carregar o ambiente gráfico, depois do upgrade. — O boot terminava em tty1, pedindo Login, senha, — e depois disso tinha de comandar “startx” para carregar a sessão Plasma (a configuração é de Login automático, sem passar pelo Display manager).

Alto uso de CPU, — mesmo fora do Chromium e das “Páginas” do Facebook

Como efeito colateral (acho), tornou-se impraticável a navegação, rolagem vertical e compartilhamento de “Páginas” do Facebook (não Feed, Perfis, Grupos) no Chromium.

Tudo indica que isso não foi causado pela migração para o Plasma 5.11.0, — que provavelmente apenas potencializou outro problema, mais antigo: — No início do ano, foi deletada por acidente a partição do antigo KDE Neon, e ao reinstalar surgiram complicações.

• Ver “Acidente fatal” (abaixo).

Afinal, tudo aquilo (e muito mais) acabou por ser lembrado, — só que, agora, foi necessário escolher um pacote diferente do usado em 2016:

Commit Log for Wed Oct 11 21:20:34 2017

Removed:

neon-desktop
plasma-wayland-desktop
xserver-xorg-video-intel-arbiter
xserver-xorg-video-intel-native-modesetting

Installed:

libxvmc1 ...
xserver-xorg-video-intel-hwe-...

Depois disso, o KDE Neon passou a carregar normalmente, — Grub de volta ao “quiet splash”, — e a navegação em “Páginas” do Facebook voltou à leveza e agilidade que caracterizavam o KDE Neon até Março deste ano. Três coelhos de uma vez.

Uso menos agressivo de CPU pelo “System settings” (Sidebar format) no Arch KDE Plasma 5.11.0

Infelizmente, isto não melhorou o desempenho do novo formato “Barra lateral” das Configurações do sistema (System settings) no KDE Neon. — Pelo contrário, agora usa 92% das CPUs (e não 86%), após o “conserto” do KDE Neon.

O Histórico do Synaptic não registra “a volta” dos pacotes “xserver-xorg-video-intel-arbiter” e “xserver-xorg-video-intel-native-modesetting”, — só uma atualização, em 21 Set. 2017. — Portanto, já vieram na nova ISO, ao reinstalar o KDE Neon, em Abril, e por isso não chamaram atenção para um momento específico, como em 25 Out. 2016.

Embora registrado aqui no Byteria, aquele problema do final de 2016 só foi lembrado após uma conversa no Google+, com outro usuário do KDE Neon que também enfrentou problemas, agora, na chegada do Plasma 5.11.0.

Diferenças de desempenho perante o recurso “Páginas” (não Feed, Grupos, Perfis) do Facebook

Neste hardware, a questão está ligada ao controlador gráfico (onboard) Intel i915, — que em 2016 parecia não ser problema no KDE Neon, — e que talvez tenha relação também com alguns problemas do Linux Mint, após o upgrade de 18 Sarah Beta para 18.1 Serena, em 28 de Janeiro deste ano (ainda não totalmente solucionado).

Aliás, esse foi o motivo de recuar para o Kernel 4.4.0 no KDE Neon reinstalado (veio com 4.8.0), — e reinstalar o Mint 18 Sarah. — Tentativas de “voltar ao tempo feliz”.

Até parecia uma “tendência”, e estava se tornando preocupante, porque instalações novas do Kubuntu 17.04 Zesty Zapus e do Mint 18.2 Sonya também abriram o bico perante as “Páginas” do Facebook, — primeiro “indicador” percebido no dia-a-dia, muito antes de entender a origem dessa diferença de desempenho entre diferentes distros Linux.

Por outro lado, essa descoberta talvez permita não só “consertar” as novas versões do Mint e do Kubuntu, — como, talvez, melhorar o desempenho do Debian, do Arch, do Devuan, — e um dia, quem sabe, até o do Slackware.

São exemplos concretos daquela dica de se usar distros estáveis em ambiente de produção, e rolling-release apenas quando se desejam emoções fortes, — ou ambas (em dualboot), se você não consegue se decidir, — já que avanços, muitas vezes, trazem “regressões”, como diz Clem / Mint.

Em alguns casos, como esse, se podem resolver com alguma pesquisa & leitura. Em outros, uma correção acaba chegando alguns dias ou semanas depois. Mas também há casos que parecem ter vindo para ficar, — como o fim da Barra lateral (F9) do Konqueror, ou a impossibilidade de continuar atribuindo “Esc” como atalho para fechar o Gwenview. Neste, o botão “Ajustar” também deixou de alternar (togle) “100%”, — Agora, são necessários 2 botões.

Enfim, desde essas reinstalações complicadas do KDE Neon e do Mint 18 KDE, voltei a queimar todas as ISOs em DVD / CD, para guardar.

Kernel, GoogleEarth, Wine

Kernel recomendado pelo Synaptic para o KDE Neon User Edition

Desde a reinstalação, em Abril, vinha adiando várias configurações para o trabalho diário, — afinal, talvez acabasse reinstalando mais uma vez (ou várias), — e não valia a pena investir tempo para depois começar tudo de novo.

Confirmado o “conserto” do problema, — após vários dias de uso, — chegou a hora de deixar o KDE Neon pronto para (quase) tudo, tal como era antes.

15 Out. 2017 - Foi instalado o Kernel mais recente, conforme o Synaptic vinha recomendando há tempos. — A versão sugerida pelo Synaptic era 4.10.0-37, — a mesma incluída na mais recente daily-build do KDE Neon User Edition (neon-useredition-20171012-1018-amd64).

GoogleEarth finalmente instalado e funcionando, — sem placa 3D aceleradora, — no KDE Neon

Após mais algumas horas de bom funcionamento do KDE Neon (com o Kernel atual), foi instalado o GoogleEarth, — sem placa 3D aceleradora, — aproveitando o registro das saídas dos comandos em 2016.

Dos pacotes necessários em 2016, vários não foram encontrados agora pelo Synaptic:

googleearth-package
mesa-utils
lsb-core
gdebi (optei por não usar)
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
multiarch-support

Ao invés de iniciar uma longa pesquisa de eventuais alternativas e dicas atualizadas, — com grande probabilidade de encontrar orientações contraditórias e perder muito tempo, — apenas foi reiniciado o computador e disparado o comando seguinte:

flavio@Linux1:~$ sudo dpkg -i googleearth_6.0.3.2197+1.2.0-1_amd64.deb
[sudo] password for flavio:
(Lendo banco de dados ... 252554 ficheiros e directórios actualmente instalados.)
A preparar para desempacotar googleearth_6.0.3.2197+1.2.0-1_amd64.deb ...
A descompactar googleearth (6.0.3.2197+1.2.0-1) sobre (6.0.3.2197+1.2.0-1) ...
dpkg: problemas com dependências impedem a configuração de googleearth:
 googleearth depende de libcurl3:i386.
 googleearth depende de libsm6:i386.
 googleearth depende de libfontconfig1:i386.
 googleearth depende de libxt6:i386.
 googleearth depende de libxrender1:i386.
 googleearth depende de libxext6:i386.
 googleearth depende de libgl1-mesa-glx:i386.
 googleearth depende de libgl1-mesa-dri:i386.

dpkg: erro ao processar o pacote googleearth (--install):
 problemas de dependência - deixando desconfigurado
A processar 'triggers' para desktop-file-utils (0.22-1ubuntu5.1) ...
A processar 'triggers' para mime-support (3.59ubuntu1) ...
A processar 'triggers' para shared-mime-info (1.5-2ubuntu0.1) ...
Erros foram encontrados durante o processamento de:
 googleearth

A lista de dependências foi transformada em uma linha de comando, na expectativa de que as respostas indicariam novos passos.

De fato, o comando tropeçou em vários problemas, — mas indicou uma solução:

flavio@Linux1:~$ sudo apt install libcurl3:i386 libsm6:i386 libfontconfig1:i386 libxt6:i386 libxrender1:i386 libxext6:i386 libgl1-mesa-glx:i386 libgl1-mesa-dri:i386
Lendo listas de pacotes... Pronto
Construindo árvore de dependências     
Lendo informação de estado... Pronto
Você deve querer executar 'apt-get -f install' para corrigí-los:
Os pacotes a seguir têm dependências desencontradas:
......... (lista enorme de problemas) .........
E: Dependências desencontradas. Tente 'apt-get -f install' sem nenhum pacote (ou especifique uma solução).

O comando sugerido operou maravilhas de engenharia:

flavio@Linux1:~$ sudo apt-get -f install
Lendo listas de pacotes... Pronto
Construindo árvore de dependências     
Lendo informação de estado... Pronto
Corrigindo dependências...Starting pkgProblemResolver with broken count: 0
Starting 2 pkgProblemResolver with broken count: 0
Done
 Pronto
Starting pkgProblemResolver with broken count: 0
Starting 2 pkgProblemResolver with broken count: 0
Done
Os seguintes pacotes foram instalados automaticamente e já não são necessários:
  kate kate5-data linux-headers-4.4.0-96 linux-headers-4.4.0-96-generic linux-image-4.4.0-96-generic
  linux-image-extra-4.4.0-96-generic plasma-workspace-wayland
Utilize 'sudo apt autoremove' para os remover.
The following additional packages will be installed:
  gcc-5-base:i386 libbsd0:i386 libcurl3:i386 libdrm-amdgpu1:i386 libdrm-intel1:i386 libdrm-nouveau2:i386
  libdrm-radeon1:i386 libdrm2:i386 libedit2:i386 libelf1:i386 libexpat1:i386 libfontconfig1:i386 libfreetype6:i386
  libgl1-mesa-dri:i386 libgl1-mesa-glx:i386 libglapi-mesa:i386 libgssapi-krb5-2:i386 libice6:i386 libk5crypto3:i386
  libkeyutils1:i386 libkrb5-3:i386 libkrb5support0:i386 libllvm4.0:i386 libpciaccess0:i386 libpng12-0:i386
  librtmp1:i386 libsensors4:i386 libsm6:i386 libstdc++6:i386 libtinfo5:i386 libtxc-dxtn-s2tc0:i386 libuuid1:i386
  libx11-6:i386 libx11-xcb1:i386 libxau6:i386 libxcb-dri2-0:i386 libxcb-dri3-0:i386 libxcb-glx0:i386
  libxcb-present0:i386 libxcb-sync1:i386 libxcb1:i386 libxdamage1:i386 libxdmcp6:i386 libxext6:i386 libxfixes3:i386
  libxrender1:i386 libxshmfence1:i386 libxt6:i386 libxxf86vm1:i386
Pacotes sugeridos:
  krb5-doc:i386 krb5-user:i386 lm-sensors:i386
Os NOVOS pacotes a seguir serão instalados:
  gcc-5-base:i386 libbsd0:i386 libcurl3:i386 libdrm-amdgpu1:i386 libdrm-intel1:i386 libdrm-nouveau2:i386
  libdrm-radeon1:i386 libdrm2:i386 libedit2:i386 libelf1:i386 libexpat1:i386 libfontconfig1:i386 libfreetype6:i386
  libgl1-mesa-dri:i386 libgl1-mesa-glx:i386 libglapi-mesa:i386 libgssapi-krb5-2:i386 libice6:i386 libk5crypto3:i386
  libkeyutils1:i386 libkrb5-3:i386 libkrb5support0:i386 libllvm4.0:i386 libpciaccess0:i386 libpng12-0:i386
  librtmp1:i386 libsensors4:i386 libsm6:i386 libstdc++6:i386 libtinfo5:i386 libtxc-dxtn-s2tc0:i386 libuuid1:i386
  libx11-6:i386 libx11-xcb1:i386 libxau6:i386 libxcb-dri2-0:i386 libxcb-dri3-0:i386 libxcb-glx0:i386
  libxcb-present0:i386 libxcb-sync1:i386 libxcb1:i386 libxdamage1:i386 libxdmcp6:i386 libxext6:i386 libxfixes3:i386
  libxrender1:i386 libxshmfence1:i386 libxt6:i386 libxxf86vm1:i386
0 pacotes atualizados, 49 pacotes novos instalados, 0 a serem removidos e 0 não atualizados.
1 pacotes não totalmente instalados ou removidos.
É preciso baixar 23,0 MB de arquivos.
Depois desta operação, 196 MB adicionais de espaço em disco serão usados.
Você quer continuar? [S/n]

Foi ignorada a sugestão de auto-remover o Kate, — usado de 5 em 5 minutos, — ou o Kernel obsoleto (na verdade existem 2 anteriores), pois não afeta em nada a instalação do GoogleEarth.

Foi tentado instalar os 3 pacotes sugeridos, — mas a saída foi de centenas de linhas (mais do que o Konsole guarda, para copiar), — e afinal, está claro que não eram indispensáveis.

Por fim, o velho comando para organizar a bagunça indicou que já estava tudo Ok, graças ao comando anterior:

flavio@Linux1:~$ 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
Starting pkgProblemResolver with broken count: 0
Starting 2 pkgProblemResolver with broken count: 0
Done
Os seguintes pacotes foram instalados automaticamente e já não são necessários:
  kate kate5-data linux-headers-4.4.0-96 linux-headers-4.4.0-96-generic linux-image-4.4.0-96-generic
  linux-image-extra-4.4.0-96-generic plasma-workspace-wayland
Utilize 'sudo apt autoremove' para os remover.
0 pacotes atualizados, 0 pacotes novos instalados, 0 a serem removidos e 0 não atualizados.

Para registro, — os comandos que de fato fizeram o trabalho, — após instalar pelo Synaptic tudo que era fácil de encontrar:

•  1005  sudo apt update
•  1007  make-googleearth-package --force
•            (reboot)
•  1009  sudo apt update
•  1011  sudo dpkg -i googleearth_6.0.3.2197+1.2.0-1_amd64.deb
•  1019  sudo apt-get -f install
•  1023  sudo apt-get install -y -f

Depois disso, bastou chamar o GoogleEarth pelo Menu, — e já apareceu com os lugares herdados da /home do antigo KDE Neon.

CorelDraw instalado em 2016 ainda lembrava o último arquivo aberto, — só faltava o Wine

A parte mais simples foi a reinstalação do Wine, — o apt / Synaptic automaticamente inclui Wine-gecko, Wine-mono, Winetricks e dezenas de dependências.

Configuração das bibliotecas que faltavam no Wine

Os programas instalados ficam em /home/.wine/ — portanto, foram preservados, com as antigas configurações, bem como a das “unidades” E:\ (/Sites) e F:\ (/Works). — Bastou adicionar algumas das bibliotecas que não apareciam na lista ativa.

Feito isso, foi só abrir o Menu K, e lá estavam os velhos programas, prontos para o trabalho.

Histórico das transições

As datas podem não corresponder à liberação oficial, — pois o KDE Neon nem sempre é usado e atualizado todos os dias. — O mais certo é rodar e atualizar todas as distros instaladas, pelo menos uma vez por semana.

10 Out. KDE 5.11.0
 7 Set. Fwk 5.38
25 Ago. KDE 5.10.5
15 Ago. Fwk 5.37
25 Jul. KDE 5.10.4
11 Jul. Fwk 5.36
28 Jun. KDE 5.10.3
16 Jun. KDE 5.10.2
12 Jun. Fwk 5.35
 7 Jun. KDE 5.10.1
30 Mai. KDE 5.10.0
20 Mai. Fwk 5.34
28 Abr. KDE 5.9.5
17 Abr. Fwk 5.33
22 Mar. KDE 5.9.4
****** Reinstall ******
 1 Mar. KDE 5.9.3
15 Fev. Fwk 5.31
15 Fev. KDE 5.9.2
 7 Fev. KDE 5.9.1
 4 Fev. KDE 5.9.0
19 Jan. Fwk 5.30
29 Dez. KDE 5.8.5
14 Dez. Fwk 5.29
23 Nov. KDE 5.8.4
19 Nov. Fwk 5.28
 2 Nov. KDE 5.8.3
19 Out. KDE 5.8.2
12 Out. KDE 5.8.1
10 Out. Fwk 5.27
 4 Out. KDE 5.8.0
15 Set. KDE 5.7.5
13 Set. Fwk 5.26
26 Ago. KDE 5.7.4
16 Ago. Fwk 5.25
 4 Ago. KDE 5.7.3
22 Jul. KDE 5.7.2
13 Jul. KDE 5.7.1
12 Jul. Fwk 5.24
 6 Jul. KDE 5.7.0
16 Jun. KDE 5.6.5
14 Jun. Fwk 5.23

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

• Acidente fatal
• Transição para KDE 5.9
• Transição para KDE 5.8
• Transição para KDE 5.7

Acidente fatal

Destruição acidental da antiga partição do KDE Neon

19 Mar. 2017 - Tanto cuidado em conferir e tornar a conferir a partição certa, para instalar o Mageia, — planilha na tela; anotações em papel para reforçar, — e acabei errando ao preencher o diálogo.

Ok, acontece. — Bastava baixar uma ISO do KDE Neon e instalar de novo, — após mover o Mageia para a partição certa.

Acontece que todas as Inovas SOs baixadas apresentaram falhas em rodar uma sessão Live no meu hardware. — O mesmo hardware onde rodaram 2 Lives do KDE Neon e foram feitas 2 instalações em HDD, no ano anterior, — com antigas ISOs que não guardei e não consegui obter de novo.

Live USB em Abril de 2017

Em todas as tentativas, até Abril, foi impossível rodar sessões Live DVD / Pendrive do KDE Neon 5.9, — com diferentes ISOs (sempre verificando sha256sum, gravação). — Tudo que obtinha era uma tela tty1 piscando e pedindo Login e senha.

A alternativa escolhida foi instalar, — não em sessão Live, mas como mero “CD de Instalação”, — direto do Menu de Boot, que só oferecia essas 2 opções.

Depois de instalado (2 ou 3 vezes), o resultado era sempre o mesmo, — uma tela tty1 intermitente, tipo vaga-lume. — O jeito foi aceitar, e procurar remédio.

Para contornar o problema, uma vez ou outra, bastou seguir uma velha manha, — entrar pelo Modo de recuperação (Recovery mode), e não fazer nada, — apenas Prosseguir com o boot (Resume). Isso carrega uma sessão incompleta, ou seja, sem algum driver de video. É um modo de ter acesso à interface gráfica, numa emergência. Mas é chato ter de fazer isso todos os dias.

Uma solução provisória foi editar o grub.cfg, — substituir “quiet splash” por “nomodeset”. — Portanto, desde Abril deste ano, o KDE Neon vinha rodando fora do padrão.

Ia passando desapercebido que um problema semelhante, de tty1 + Login + startx, já havia ocorrido após uma atualização corriqueira, em 25 Out. 2016, — com a diferença de que, no ano passado, o tty não ficava piscando, e o comando “startx” acabava em mensagem de erro.

• Ver “Problemão” (abaixo, em “Transição para KDE 5.8”).

Desta vez, a solução só veio a ser encontrada em Outubro 2017, após a transição para o Plasma 5.11 (acima).

Transição 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.

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.

• Uma pista → “Plasma 5.6.1 got rid of desktop theme advanced customization”
• Relato da solução provisória → Kubuntu 17.04 Zesty Zapus (development branch)
• Registro dos pacotes envolvidos na transição para o KDE 5.8

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.

• Registro das “atualizações” do KDE Neon 5.6 para 5.7

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.

• Registro das “atualizações” do KDE Neon 5.6 para 5.7

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 PIM - “Personal Information Manager”, — que não veio com a instalação do KDE Neon User Edition.

• 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

• openSUSE Leap 42.2 - Instalação e configuração
• Instalação do Manjaro KDE 16.10.3 stable
• Upgrade do Linux Mint para KDE 5.8.4
• Kubuntu 17.04 Zesty Zapus daily-build em drive SSD
• Testes Live USB com o Kubuntu 16-10 Yakkety Yak
• Crash no instalador do Kubuntu 16.10 Yakkety Yak (Beta)
• Instalação do Linux Mint 18 “Sarah” KDE (Beta)
• Linux Mint 18 KDE (Beta) em Live USB
• Kurumin Linux (2003-2008)
• KDE “light” eliminando o PIM
• Transição automática do KDE Neon 5.6 para 5.7
• Instalação do KDE Neon User Edition
• Google Earth no KDE Neon e Kubuntu 16.04
• Linux ficou sem Administrador. Que fazer?
• Particionamento de HDs para 4 Linux
• Live KDE Neon Plasma Wayland Dev Edition (Unstable)
• Baloo consumindo CPU no Kubuntu 16.04 LTS
• Instalação do Kubuntu 16.04 LTS em 34 minutos
• Teste do Kubuntu 16.04 LTS em Live USB
• 4º Teste em Live Kubuntu Xenial beta2: — OCR e Scanner USB
• 3º Teste em Live Kubuntu Xenial beta2: — Discover e Spectacle
• 2º Teste de trabalho no Kubuntu 16.04 Xenial beta2 em Live USB
• 1º Teste de trabalho no Kubuntu 16.04 Xenial beta em Live USB
• Google Earth no Kubuntu amd64 (64bit)
• Google Earth no Kubuntu i386 (32bit)
• Pacotes instalados no Kubuntu 14.04 ao ser substituído (24 Abr. 2016)
• Histórico de instalação de pacotes no Kubuntu 14.04 LTS (2014-2016)
• Instalação do Kubuntu 14.04 Desktop amd64 (LTS)
• Configurando o teclado no Kubuntu 14.04
• Testando o Ubuntu 14.04 LTS a partir do “Live DVD”
• Migrando do Kubuntu 12.04 para 14.04 num domingão
• Dual boot, GRUB, StartUpManager, Ubuntu 12.04, Grub-customizer
• Instalação do Kubuntu 12.04
• Configuração manual de partições para o Linux (e Windows, também!)