Translate

Mostrando postagens com marcador PIM. Mostrar todas as postagens
Mostrando postagens com marcador PIM. Mostrar todas as postagens

quinta-feira, 17 de maio de 2018

Devuan 2 Beta KDE - Desastre e recuperação

Início do desastre com o KDE Plasma (testing) no Devuan 2 Beta

21 Abr. 2018 - O desastre com o KDE Plasma do Devuan 2 Beta foi causado, provavelmente, por alguma alteração na teia de dependências, — envolvendo dezenas de pacotes do PIM & Akonadi removidos 2 meses antes, — e de certo modo acabou funcionando como um “freio de arrumação”.

  • Ver “Release Candidate e mudança de status do KDE” (adiante)

Em resumo, as atualizações propostas pelo Synaptic implicavam em remover o próprio Synaptic e alguns pacotes críticos do KDE, Polkit, gerenciador de Rede etc.

Além de não “entender” muita coisa do GNU / Linux, eu devia estar com a atenção meio dividida entre outras questões, — Cooler entupido, Grub doido, Manjaro chucro, — mas, por mais que examine hoje aquele dilema, continuo sem imaginar o que poderia fazer naquela situação.

O Synaptic resistiu bravamente, até o final, — registrou até o log de sua própria remoção, — mas esperar que, em seguida, ainda abrisse o Histórico, para exibir a façanha… Bom, aí talvez já fosse querer demais.

Índice


  • Sem rede
  • Demolição do KDE em capítulos
  • Existe vida sem KDE
  • Recuperação do KDE
  • De volta para o futuro
  • Release Candidate e mudança de status do KDE
  • Outras configurações
  • PIM & uso inicial de RAM
  • Remoção do Akonadi
  • O caso do Debian testing

Referências



Sem rede


Falha de Rede ao tentar reinstalar o Synaptic

12:55 - Ao tentar apt install synaptic, nenhum dos 4 pacotes previstos pôde ser obtido. — O mais provável é que fosse falha de Rede, afinal tinha acabado de remover network-manager, — mas se este fosse o caso, como reinstalar esse pacote… sem Rede?

Tampouco podia descartar a possibilidade de falha nos repositórios, — embora ainda não saiba como direcionar para um ou outro espelho (Mirror). — De qualquer modo, parece que são poucos, todos na Europa, exceto 1 no Chile (e nenhum no Brasil, por enquanto).

A experiência dos últimos 3 meses já tinha mostrado que, às vezes, a velocidade de acesso aos repositórios cai a níveis exasperantes. Várias vezes, também, um mero apt update (Reload, no Synaptic) já terminou em erro, — sem que houvesse qualquer falha de Rede (navegação normal), — e bastava tentar de novo algumas horas depois, para encontrar tudo normalizado.

Mas dessa vez, mesmo sem alcançar nenhum repositório, o apt install deixou um aviso alarmante, — uma tonelada de pacotes (praticamente todo o KDE Plasma, além do LibreOffice e mais alguma coisa!) “já não são necessários”, — “Utilize apt autoremove para os remover”.

LibreOffice “auto-removível” desde Fevereiro

A rigor, isso nem era novidade, — desde a remoção do PIM & Akonadi, em Fevereiro, o Synaptic já listava 208 pacotes “Removíveis” (incluindo todo o LibreOffice), que nem por isso deixavam de receber atualizações, — mas a apresentação desse dilema, agora, soou como um ultimato: não dava mais para ignorar.

Só que, agora, tratava-se de remover 300 pacotes, — mas isso ficou para a semana seguinte.

Em todo caso, minutos depois o Chromium confirmou que, de fato, estava sem Rede.

Demolição do KDE em capítulos


Colapso do KDE Plasma e Reboot pelo tty3

Em seguida, o Menu deixou de responder, — provavelmente, o KDE só estava funcionando por inércia (pré-carregado), e cada iniciativa que dependesse de um pacote removido, ia demolindo o ambiente, pedaço por pedaço.

Feito o Reboot, — por comando Root a partir do tty3, — o Devuan carregou com o Painel desmantelado, Menu inoperante; e o Conky em fundo preto, confirmando zero tráfego de Rede.

Nestas circunstâncias, as fotos de celular são muito pouco úteis, — quase todas mal focadas (letras miúdas), — exceto para datar os acontecimentos.

Não houve mais Capturas de tela, — mas não há registro de que tenha tentado fazê-las, — nem de que a tecla PrtScn ou o gnome-screenshot se recusassem a funcionar.

Existe vida sem KDE


Atualização do Grub, — com KDE desconchavado

22 Abr. 2018 - No dia seguinte, o Devuan voltou a ser carregado, — Painel desconjuntado, Menu fora de combate, Conky sobre fundo preto, — e não há registro de como consegui abrir Dolphin, Kate, Konsole (talvez pelos lançadores no Painel, que acabou se arrumando; mas o Menu não ressuscitou).

Em boa hora, acionei o gnome-screenshot pela tecla de atalho PrtScn, — e funcionou, — de modo que é possível conferir os indicadores desta sessão, com nitidez.

O objetivo, nesse dia, era apenas disparar um update-grub, — com os_prober previamente desabilitado (a partir do openSUSE), — o que reduziu o arquivo /boot/grub/grub.cfg de 552,2 KiB para 9,2 KiB, em 15 segundos.

O conserto geral do Grub era urgente, — e em certa medida, pré-requisito para poder cuidar do Devuan.

Recuperação do KDE


Confusão ao tentar um comando no Modo de recuperação (Recovery mode)

27 Abr. 2018 - Só na outra semana, finalmente foi carregado o Modo de recuperação (Recovery Mode), — que está longe de oferecer a mesma moleza do Ubuntu & derivados.

Após entrar com a Senha (para Manutenção), nem cheguei a completar o comando pretendido, — que pretendia ser apt-get install -f, — e o sistema já começou (ou continuou) a dar retorno de outras coisas, sem qualquer relação.

Removendo tudo que o apt queria, — basicamente, todo o KDE Plasma

Mas o histórico não deixa dúvida, — de fato apenas tentei atualizar o apt (sem rede!), — e já mandei remover aquilo tudo, que vinha sendo proposto, para deixar de repetir sempre a mesma ladainha, a cada passo que se tentava dar:

# apt-get install
# apt update
# apt autoremove
# reboot

Ativando e testando a Rede, para rodar o Tasksel

Embora tenha pesquisado e anotado vários comandos para configuração de Rede, apenas um funcionou, — e foi mais do que suficiente, para restabelecer a conexão.

Depois, bastou testar, — e rodar o Tasksel em seguida:

# dhclient eth0
# ping 8.8.8.8
# tasksel

Re-instalando o KDE pelo Tasksel

No Tasksel, foi selecionado apenas o KDE, — e para minha surpresa trouxe de volta o LibreOffice, — que, desde então, nunca mais o apt / Synaptic classificou como “Removível”… até remover o Akonadi outra vez.

Velocidade de Rede inferior à “conexão discada” da antiguidade

Infelizmente, o processo todo demorou mais de 1h10min (16:52 ~ 18:05), — com o Conky (tty7) indicando download em velocidade inferior à da Idade da Pedra.

Devuan 2 Beta com KDE reinstalado e (quase) todas as configurações intactas, — após 1h28min

Ainda no tty7, apenas foi encerrada a sessão (por Ctrl-Alt-Del + Enter), — feito novo Login, — e a nova sessão já exibiu o KDE inteiro, zerado, com (quase) tudo configurado como antes.

De volta para o futuro


Ao contrário do padrão original, o 1º usuário já não era Administrador

Foi necessário tornar a configurar alguns detalhes:

  • Reinstalar o Synaptic (pelo Apper) - download entre 28 ~ 43 KiB/s
  • Passar novamente o Compositor de OpenGL 2.0 para XRender
  • Desabilitar novamente a Carteira do KDE (KWallet)
  • Restabelecer o Usuário principal como Administrador (sudo)

Synaptic só abria por comando Root, desde Fevereiro

Cabe lembrar que desde a instalação do Devuan 2 Beta, em Fevereiro, o Synaptic jamais abriu pelo Menu, — simplesmente abortava, — e tinha de ser chamado por comando Root.

Agora, basta clicar no Menu, — entrar com a senha Root, — e abre normalmente.

Desabilitando a Carteira de senhas do KDE (KWallet)

Mas outras coisas também melhoraram, — como se várias implementações se tivessem alterado, de Fevereiro para cá, — e o “acidente de percurso” tenha funcionado como um “freio de arrumação”.

Desta vez, por exemplo, desabilitar o KWallet funcionou sem problemas.

Release Candidate e mudança de status do KDE


No Tasksel, KDE, Cinnamon e LXQt deixaram de ser apresentados como “Testing”

De fato, houve uma atualização do Tasksel (+data) em 16 Abril, — uma semana antes do desastre, — e é possível que aí tenham chegado algumas mudanças nas dependências dos pacotes, com as quais a situação anterior talvez fosse incompatível.

Aliás, parece ter havido alguma aceleração nas mudanças do Tasksel: — Uma única atualização, de Fevereiro até Abril, — e agora três, em cerca de 30 dias:

Apr 16 - tasksel (3.39+devuan1.6.1) to 3.39+devuan1.7
May 5  - tasksel (3.39+devuan1.7) to 3.39+devuan1.8
May 17 - tasksel (3.39+devuan1.8) to 3.39+devuan1.9

Em algum momento, — infelizmente, não percebido e não-documentado, — o Tasksel deixou de exibir a advertência de “Testing” para o KDE, o Cinnamon e o LXQt.

Embora o desastre tenha ocorrido em 21 de Abril, — possivelmente em decorrência de alterações trazidas pela atualização de 16 de Abril, — parece muito provável que já prenunciassem o RC oficialmente divulgado em 9 de Maio.

O anúncio frisa, especificamente, que o instalador “agora oferece uma variedade mais ampla de ambientes, incluindo XFCE, KDE, MATE, Cinnamon, LXQt”:

Devuan 2.0 ASCII Release Candidate
2018-05-09 22:26:51
We are happy to announce that the Devuan 2.0 ASCII Release Candidate is now available thanks to the support, feedback, and collaboration of the Devuan community. Devuan 2.0 ASCII Stable will be following soon.

The Devuan 2.0 ASCII RC installer now offers a wider variety of Desktop Environments including XFCE, KDE, MATE, Cinnamon, LXQT (with others available post-install).  In addition, there are options for "Console productivity" with hundreds of CLI and TUI utils, as well as a minimal base system ideal for servers.

When installing from ISO, the expert install option offers a choice of SysVinit and OpenRC. Official ready-to-use Devuan 2.0 ASCII RC images are available for dozens of ARM boards and SOCs, including Raspberry Pi, BeagleBone, OrangePi, BananaPi, OLinuXino, Cubieboard, Nokia N900, and several Chromebooks, as well as for Virtualbox/QEMU/Vagrant.

Outras configurações


Desde a instalação do Devuan 2 Beta (Fevereiro), ficaram faltando 2 configurações, — que já são hábito antigo, nas demais distros instaladas, — mas ainda não havia aplicado no Devuan:

  • Remover PackageKit, — que verifica os repositórios, em horas inoportunas
  • Remover Unattended-upgrades, — que atualiza (alguns) pacotes sem pedir licença

Desinstalar PackageKit implicou na remoção do Plasma-Discover e do Apper. — Até gosto do Apper (embora prefira Synaptic), — mas evito sistematicamente o Plasma-Discover.

Por fim, faltava refazer:

  • Remover PIM & Akonadi (este último voltou a carregar 16 processos)

PIM & uso inicial de RAM


Processos Akonadi jamais usados, — carregados automaticamente a cada sessão

A reinstalação do conjunto PIM & Akonadi (completo) voltou a elevar o consumo inicial de Memória RAM, — com nada menos que 17 processos Akonadi rodando sem necessidade.

Antes do desastre:

2018-02-17 - 358 MiB - 2º Boot sem PIM & Akonadi
2018-02-17 - 355 MiB - PrtScn alterou: 357 MiB - ainda sem AutoLogin
2018-02-17 - 348 MiB
2018-02-21 - 342 MiB - PrtScn alterou: 343 MiB
2018-02-23 - 351 MiB - PrtScn alterou: 352 MiB
2018-03-03 - 365 MiB
2018-03-13 - 365 MiB - PrtScn alterou: 367 MiB
2018-03-19 - 365 MiB
2018-03-28 - 356 MiB - PrtScn alterou: 357 MiB
2018-04-01 - 371 MiB - PrtScn alterou: 372 MiB
2018-04-21 - 351 MiB - após PrtScn: 399… 352 MiB

Após a recuperação:

2018-04-27 - 514 MiB - PrtScn alterou: 517 MiB
2018-04-28 - 517 MiB
2018-04-30 - 502 MiB - PrtScn alterou: 503 MiB
2018-05-01 - 499 MiB - PrtScn alterou: 503 MiB
2018-05-05 - 501 MiB - PrtScn alterou: 503… 528… 502 MiB
2018-05-17 - 502 MiB - PrtScn alterou: 504 MiB

Após remover Akonadi-server:

2018-05-21 - 331 MiB - PrtScn alterou: 333 MiB… 358… 331 MiB
2018-05-21 - 330 MiB - PrtScn alterou: 331 MIB… 356… 331 MiB
2018-05-21 - 331 MiB - PrtScn alterou: 333 MiB… 356… 331 MiB
2018-05-22 - 332 MiB - PrtScn alterou: 333 MiB
2018-05-23 - 332 MiB - PrtScn alterou: 331 MiB
2018-05-23 - 331 MiB
2018-05-28 - 331 MiB - PrtScn-alterou: 336 MiB

Obs.: Números observados cerca de 1 minuto após o carregamento do KDE, — quando o uso de Memória RAM se estabiliza.

O primeiro número é a observação visual antes do PrtScn, — pois às vezes o gnome-screenshot interfere na Memória RAM antes da captura, e grava a imagem com um número alterado (exceto quando omitido, acima).

Entre a captura e o final da gravação, o gnome-screenshot ainda costuma elevar mais um pouco esse número (cerca de +25 MiB), retornando ao patamar inicial após cerca de +25 segundos.

Medição do uso de Memória RAM, — 1 minuto (↓) após o carregamento completo do KDE

Os gráficos de uso de CPU são de 2 minutos (120 pixels), — e o final da passagem do pequeno pico inicial pelo centro (↓) assinala 1 minuto após as notificações de carregamento completo do KDE, conexão de Rede etc.

Remoção do Akonadi


Remoção “apenas” do Akonadi-server, — um modo de remoção parcial do PIM

A primeira remoção do PIM, Baloo, Akonadi tinha sido feita logo na instalação do Devuan 2 Beta, em meados de Fevereiro, — e não causou nenhum desastre durante 2 meses.

21 Mai. 2018 - Diante da possibilidade de novos desastres, agora foi removido “apenas” o próprio Akonadi-server, — com suas dependências automáticas, — o que evitou gastar tempo à procura de vários itens, e no teste das dependências de cada um:

Efeitos da remoção “apenas” do Akonadi-server, — em comparação com a remoção de Fevereiro

Commit Log for Mon May 21 08:06:07 2018

Removed:

accountwizard
akonadi-server
akregator
kaddressbook
kde-config-mailtransport
kde-standard
kdepim-addons
kdepim-runtime
kdepim-themeeditors
kmail
knotes
korganizer
libkf5akonadicalendar5
libkf5akonadicontact5
libkf5akonadicore-bin
libkf5akonadimime5
libkf5akonadisearch-bin
libkf5akonadisearch-plugins
libkf5alarmcalendar5
libkf5calendarsupport5
libkf5eventviews5
libkf5gravatar5
libkf5incidenceeditor-bin
libkf5incidenceeditor5
libkf5kaddressbookgrantlee5
libkf5kdepimdbusinterfaces5
libkf5ksieveui5
libkf5libkdepim-plugins
libkf5libkdepim5
libkf5mailcommon-plugins
libkf5mailcommon5
libkf5mailimporter5
libkf5mailtransport5
libkf5messagecomposer5
libkf5messagecore5
libkf5messagelist5
libkf5messageviewer5
libkf5pimcommon-plugins
libkf5pimcommon5
libkf5templateparser5
libkolab1
task-kde-desktop

A lista é apenas um pouco menor, — mas remover “só” 1 pacote deu muito menos trabalho.

Agora, a lista dos “Auto-Removíveis” é de 240 pacotes, — inclusive todo LibreOffice, de novo.

O caso do Debian testing


Comparativo dos sistemas Linux instalados em 16 Mai. 2018

Só para referência, vale lembrar que o Debian foi instalado “Jessie” e transformado, — do modo mais atabalhoado possível, — em “Testing” (não “Stretch”). No devido tempo começou a se apresentar como “Stretch”, e atualmente como “Buster / Sid”.

No Debian testing, a remoção do PIM-Baloo-Akonadi foi tão completa quanto possível, — e nesses 20 meses, seu KDE evoluiu do KDE 5.8.0 até o KDE 5.12.5, — ao passo que o Devuan 2 Beta continua com o mesmo KDE 5.8.6 que tinha há 3 meses.

Não se trata de comparar a enormidade de recursos, desenvolvedores, testadores, mailing-lists, foruns etc. do Debian com o esforço heroico realizado pela brava comunidade do Devuan, — portanto, a constatação de que o Debian (mesmo sob tortura de um mentecapto) segue firme e forte, deve ser tomada única e exclusivamente como referência para análise. — Nada além disso.

Por outro lado, a recuperação (simples e fácil) do KDE Plasma foi uma demonstração cabal de solidez, consistência e capacidade de regeneração do Devuan 2 Beta, — mesmo cruelmente amputado e submetido às mais torpes torturas.

Tanto no Debian quanto no Devuan, a montagem automática de partições adicionais dos HDDs se faz pelo arquivo /etc/fstab, — e apenas as do SSD externo pelo udisks2, — via System settings >> Removable devices.

— … ≠ • ≠ … —

Without-SystemD



Debian's


Postado por Mboaba às quinta-feira, maio 17, 2018 0 comentários
Marcadores: , , , ,

quarta-feira, 2 de agosto de 2017

openSUSE - removendo Snapper, PIM, Baloo e Akonadi

Deletando manualmente snapshots que proliferam como coelhos no openSUSE. — Nem sinal do nº 258

• Este relato documenta:

1) A remoção do máximo dos pacotes que compõem o KDE-PIM, Baloo e Akonadi, — tal como “vieram”, automaticamente instalados com o openSUSE Leap 42.2 KDE, — exceto os necessários ao funcionamento de outros aplicativos, ou do sistema como um todo (“dependências”); e

2) A remoção / configuração “mínima (necessária)” para desabilitar o funcionamento do Snapper, — cuja função é gerar sucessivos “instantâneos” (snapshots) do Sistema, que permitem reverter (roll-back) passos “infelizes”, causados por atualizações, instalação de novos pacotes etc.

Mas o mais importante é que este relato documenta o “caminho de volta”, — para o caso de querer desfazer uma dessas 2 decisões.

KDE-PIM


Busca no Gerenciador de software do YaST2, ordenado pela 1ª coluna (status), — “instalados”

Não lembro (nem encontro registro) de ter utilizado regularmente os benefícios do PIM, Baloo-file, Akonadi-server & correlatos (ou seus antecessores), desde quando comecei a usar o Kubuntu e o Debian KDE, há mais de 8 anos (2009). — No entanto, estiveram ativos esse tempo todo, consumindo recursos (RAM, CPU) e reduzindo o proveito que poderia tirar do hardware, quando exigido para outros esforços.

Em 16 Mai. 2016, um comentário e um link numa comunidade me incentivaram a examinar o assunto, — e acabei removendo PIM, Baloo, Akonadi do Kubuntu, do Debian KDE, e dos demais sistemas instalados desde então.

Porém, naquela época, o procedimento básico foi marcar para remoção cada pacote de uma lista de “aplicativos finais” que não uso, — lista construída a partir de consultas ao site KDE e outras raras páginas localizadas sobre o tema:

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

Agora, no openSUSE Leap, comecei a busca por palavras-chave mais abrangentes, — “kdepim”, “baloo”, “akonadi”, — com os resultados ordenados pela primeira coluna (status), para agrupar os “instalados” no topo.

A partir daí, marquei para remoção cada pacote encontrado, — um de cada vez, para verificar as consequências, caso-a-caso.

Opções quando a remoção de um pacote afeta outros: — remover todos, manter, quebrar

Clique com o botão direito do mouse, selecione “Remover”, — e caso isso implique em remover outros pacotes, aparece uma janela de diálogo com a lista completa, e 3 alternativas para "resolução do conflito”:

  • Remover os pacotes que dependem dele
  • Manter o pacote selecionado (e os que dependem dele)
  • Quebrar as dependências

Nesse diálogo, tenha cuidado de não clicar em “Cancelar”, — pois isso não cancela a remoção solicitada antes, — apenas deixa o conflito sem solução (e você, sem saber como voltar a ele).

Para recuar, o caminho correto é selecionar a 2ª alternativa, — “Manter” o pacote cuja desinstalação iria lhe criar problemas, — e clicar em “Tentar novamente”.

Cuidado com listas apenas parcialmente exibidas, — verifique se não existe “mais…”

Tenha cuidado, também, com listas abreviadas ou incompletas, — com “mais…” escondido lá embaixo. — Ali mora o perigo.

Examine a lista, item por item. — Certifique-se de que não inclua nada vital ao sistema (Plasma workspace), nem algum aplicativo que você deseja manter (Dolphin, KFind, Okular, Ktorrent, Digikam, por exemplo).

Nestes casos específicos, recue, — e prossiga com a marcação dos demais pacotes encontrados.

Desativação da “Pesquisa de arquivos” (File search) nas Configurações do sistema (System settings)

É necessário ser tão radical? Nem tanto.

Desabilitar os serviços correspondentes, em várias seções das “Configurações do sistema” (KDE System settings), — como “Pesquisa de arquivos”(*), por exemplo, — é suficiente para que a maioria deles não carregue automaticamente, no início de cada sessão. Então, bastaria ter o cuidado de não clicar por distração no Kmail, Korganizer, Kalendar etc., para não acordar metade da tropa.

(*) Desativar “Pesquisa de arquivos” jamais afetou o mecanismo de pesquisa simples do Dolphin (Localizar), — nem o mecanismo de pesquisa avançada “Procurar arquivos / pastas” (KFind), — que continuam plenamente capazes de encontrar qualquer arquivo existente nos 3 HDDs + SSD externo (total 2,64 TB), por nome, extensão, tipo, data, tamanho, proprietário (User, Group) e/ou conteúdo (string dentro do arquivo), com a mesma velocidade de 2009 a 2016 (antes de começar a remover PIM, Baloo, Akonadi).

De início, foi o que fiz no openSUSE Leap 42.2, — como em outros sistemas acabados de instalar, — enquanto estes serviços ficaram quietos. Depois, começam os ajustes finos, e você acaba encontrando notificadores que resistem a desaparecer, e alguns serviços que insistem em ser carregados.

Depois de remover o que era possível, com as 3 palavras-chave, não foi necessário procurar o resto da antiga lista, — Kmail, Korganizer etc., — exceto para confirmar que já estavam desinstalados.

Dessa vez, portanto, bastou seguir o caminho inverso, — eliminar as “dependências”, — e os aplicativos caíram por tabela.

O resultado final foi a remoção de nada menos que 136 pacotes:

akonadi-calendar-lang
akonadi-calendar-tools
akonadi-calendar-tools-lang
akonadi-import-wizard
akonadi-import-wizard-lang
akonadi-mime
akonadi-mime-lang
akonadi-notes-lang
akonadi-server
akonadi-server-lang
akonadi-server-sqlite
akregator
akregator-lang
baloo5
baloo5-file
baloo5-lang
baloo5-tools
calendarsupport
calendarsupport-lang
eventviews
eventviews-lang
grantleetheme
grantleetheme-lang
incidenceeditor
incidenceeditor-lang
kaddressbook
kaddressbook-lang
kalarmcal
kalarmcal-lang
kcalutils
kcalutils-lang
kdav
kdepim-addons
kdepim-addons-lang
kdepim-apps-libs
kdepim-apps-libs-lang
kdepim-runtime
kdepim-runtime-lang
kdepimlibs4
kidentitymanagement-lang
kimap-lang
kldap
kldap-lang
kleopatra
kleopatra-lang
kmail
kmail-account-wizard
kmail-account-wizard-lang
kmail-application-icons
kmail-lang
kmailtransport
kmailtransport-lang
knotes
knotes-lang
kontact
kontact-lang
kontactinterface-lang
kopete
korganizer
korganizer-lang
kpimtextedit
kpimtextedit-lang
ktnef-lang
libgravatar
libgravatar-lang
libkdepim
libkdepim-lang
libKF5AkonadiAgentBase5
libKF5AkonadiCalendar5
libKF5AkonadiMime5
libKF5AkonadiNotes5
libKF5AkonadiSearch
libKF5AkonadiXml5
libKF5AlarmCalendar5
libKF5CalendarSupport5
libKF5CalendarUtils5
libKF5EventViews5
libKF5GrantleeTheme5
libKF5Gravatar5
libKF5IdentityManagement5
libKF5IMAP5
libKF5IncidenceEditor5
libKF5KontactInterface5
libKF5Ldap5
libKF5Libkdepim5
libKF5LibkdepimAkonadi5
libKF5Libkleo5
libKF5MailCommon5
libKF5MailImporter5
libKF5MailImporterAkonadi5
libKF5MailTransport5
libKF5MailTransportAkonadi5
libKF5Mbox5
libKF5PimCommon5
libKF5PimCommonAkonadi5
libKF5PimTextEdit5
libKF5Syndication5
libKF5Tnef5
libkgantt-lang
libKGantt2
libkgapi-lang
libkleo
libkleo-lang
libkolab1
libkolabxml1
libKPimGAPICalendar5
libKPimGAPIContacts5
libKPimGAPICore5
libKPimGAPITasks5
libKPimKDAV5
libksieve
libksieve-lang
libmeanwhile1
libmysqlclient_r18
libmysqlcppconn7
libotr5
libqgpgme7
libqimageblitz4
libreoffice-base-drivers-mysql
libxerces-c-3_1
mailcommon
mailcommon-lang
mailimporter
mailimporter-lang
mariadb
mariadb-client
mbox-importer
mbox-importer-lang
messagelib
messagelib-lang
pim-data-exporter
pim-data-exporter-lang
pim-sieve-editor
pim-sieve-editor-lang
pimcommon
pimcommon-lang

conforme os registros em /var/log/zypp/history, — entre 1:49 e 1:57 de 4 Ago. 2017. — Na verdade, a seleção começou 10 minutos antes, por volta de 1:39.

Foi uma “limpeza” muito mais completa, — além de muito mais rápida, — do que a registrada no Kubuntu e no Debian KDE.

Pacotes restantes do KDE-PIM, Baloo, Akonadi, — necessários ao sistema, ao Dolphin, KFind etc.

Ao final, ficam alguns componentes do KDE-PIM. — Não é uma remoção 100% completa, — mas já deixa o sistema nitidamente mais leve.

Vale notar que houve 2 “ensaios” (com erros), — primeiro, em 2 Jul., no Leap 42.2; e mais tarde, em 29 Jul., no Tumbleweed. — Agora, no Leap 42.3, finalmente consegui evitar erros.

Fica claro, de passagem, que o upgrade do Leap 42.2 para 42.3 reinstalou todo o KDE-PIM, Baloo, Akonadi.

Snapper


Particionamento previsto para atender à brincadeira por vários anos

Partições padronizadas de 25 GiB pareciam mais do que suficientes para cultivar um belo criadouro de Linux e passar vários anos apenas regando, adubando, podando, enxertando aqui e ali, — até que o openSUSE Leap 42.2, instalado em Janeiro, ameaçou “dobrar a meta” dentro de poucos meses. — E ainda nem tinha nele todos os aplicativos instalados no Kubuntu ao longo de mais de um ano.

  • 17 Jan. 2017 - Aos 27 minutos da primeira sessão, usava 5,37 GiB da partição-raiz.
  • 26 Jan. 2017 - Ao concluir a configuração básica, usava 7,33 GiB.
  • 9 Jun. 2017 - Atingiu 14,1 GiB, — consegui reduzir para 13,4 GiB (menos 0,7 GiB)
  • Depois disso, consegui reduzir para 11,0 GiB (menos 2,4 GiB, no mínimo)
  • 2 Jul. 2017 - Ao remover o PIM e reinstalar algumas coisas, foi de 11,0 GiB para 12,8 GiB. Consegui reduzir para 11,4 GiB (menos 1,4 GiB)
  • 3 Jul. 2017 - Consegui reduzir de 11,4 para 9,99 GiB (menos 1,5 GiB)

Somente nesses 4 episódios, — e deixando outros de lado, — o acúmulo eliminado manualmente já somava 6 GiB.

Ao iniciar o upgrade, em 3 Ago. 2017, o espaço usado já estava novamente em 11,5 GiB, — portanto, estaria em 17,5 GiB (pelo menos), caso não tivesse feito essas eliminações de pares de snapshots.

Durante o upgrade, o uso de espaço na partição-raiz chegou a 16,9 GiB, — ou seja, ultrapassaria 22,9 GiB, no mínimo.

Deletando pares de snapshots do openSUSE, — após atingir 17,0 GiB de espaço usado na partição

Felizmente, muito antes de chegar ao upgrade, comecei a entender, — na pele, — as implicações da partição BtrFS e dos “instantâneos” (snapshots) que, em tese, prometem desfazer (roll-back) qualquer desastre causado por alguma atualização, ou pela instalação de novos pacotes.

Na verdade, — como notou outro mortal, — nem saberia usar esse recurso, no caso de uma emergência.

Olhando os registros dos últimos 2 ou 3 anos, encontro poucos desastres onde esse recurso teria sido útil, — um triste upgrade do Linux Mint 18 “Sarah” Beta para 18.1 “Serena” (28 Jan. 2017), e uma infeliz atualização do Debian “Stretch”, quando ainda estava em desenvolvimento (30 Set. 2016).

Em suma, o “prêmio” cobrado por este “seguro” é desproporcional. — É um custo elevado, diário, permanente, — para um risco pequeno e de baixa ocorrência.

Estamos falando de um “usuário comum”, — com 1 máquina, — não de um “Administrador de sistema”.

Ter 2 ou 3 sistemas em paralelo (dualboot) é muito mais divertido. — O único problema é decidir “qual Linux usar hoje”. — É um preço que se paga com alegria e que retorna diariamente, na forma de aprendizado. De preferência, sem que se precise chegar a nenhum desastre.

Mas, o que significa “desastre”, — quando se tem vários sistemas em dualboot? — Se falha um, você usa outro.

Para quem gosta de brincar, sistema não há de faltar. — Mais valem 3 opções do que 1 “seguro”

Mesmo com o Linux Mint meio capenga, a partir de 31 Jan. 2017, — e coincidindo de deletar por acidente o KDE Neon, em 31 Mar. 2017, — ainda dispunha do Kubuntu 16.04 LTS (que nunca passou pelo risco de upgrade… embora hoje se apresente como “16.04.3”).

Ficou comprovado que 2 ou 3 Linux em paralelo, — se possível, em diferentes HDDs (e com mais de um Grub), — são um “seguro” bastante razoável, para um “usuário médio”.

E dispunha do openSUSE Leap 42.2, que, apenas 9 dias depois de instalado, — de 17 para 26 Jan. 2017, — já se colocava entre os “Top 3” no desempenho das tarefas essenciais do dia-a-dia.

Foi uma das mais gratas surpresas, — tamanha e tão rápida “usabilidade”, num sistema que jamais tinha visto antes, — após 7 anos limitado ao Kubuntu / Mint / Debian.

Deletando manualmente snapshots que proliferam automaticamente. — Nem sinal do nº 258

Portanto, pesquisei sobre o Snapper, — e deletei manualmente vários pares de snapshots, — até optar por desativar este serviço.

Limitando a proliferação de “instantâneos” (snapshots) no openSUSE

Primeiro, algumas providências para limitar o número de “instantâneos” (snapshots).

# snapper -c root set-config "NUMBER_LIMIT=2"
# snapper -c root set-config "NUMBER_LIMIT_IMPORTANT=2"

Desabilitando o uso do Snapper no openSUSE

Depois (pensando bem), desativar o Snapper, — editando USE_SNAPPER="yes" para "no", na última linha do arquivo “/etc/sysconfig/yast2”.

Normalmente, faria isso chamando “Dolphin - modo Root” pelo Menu K e clicando no arquivo para editá-lo com o Kate ou KWrite.

Porém, como se têm reforçado advertências contra o uso de aplicativos gráficos como Superusuário (Root), — e em várias distros essa opção já foi até eliminada do Menu, — padronizei o hábito de fazer esse tipo de trabalho pelo editor (F4) do Midnight-Commander (mc / mcedit, ou mc / nano).

Desinstalando “snapper-zypp-plugin” do openSUSE

Por fim (pensando melhor ainda), acabei por desinstalar o snapper-zypp-plugin, para acabar com a geração automática de pares de “instantâneos” (snapshots) do sistema, a cada atualização / instalação / remoção de pacotes.

Sim, porque você abre o Gerenciamento de software do YaST2, — desinstala 1 pacote, ou 100 pacotes, — e o espaço usado na partição-raiz… dá um salto.

Desinstalar esse plugin foi uma decisão de “usuário comum” (average user), — muito longe das responsabilidades de um Administrador de sistema. — Trata-se de um recurso poderoso. Apenas, nem sempre vale o “custo”, para um simples mortal.

Ao fazer upgrade do openSUSE 42.2 para 42.3, alguns pacotes removidos voltaram a se instalar e funcionar automaticamente, — todo o KDE-PIM, Akonadi, Baloo, — e o snapper-zypp-plugin.

Tudo bem, voltei a removê-los, — exceto snapper-zypp-plugin (por enquanto), — e a deletar 3 novos pares de shapshots. Já estava bem adestrado nessa arte.

Descoberta do “unreferenced snapshot” nº 258, completamente desgarrado

A decisão de não tornar a desinstalar o snapper-zypp-plugin, — por enquanto, — acabou justificada pela descoberta de um snapshot desgarrado (unreferenced snapshot), de nada menos que 6,19 GiB,

Isso, quando já estavam deletados todos os outros snapshots, — exceto nº 0 (sistema atual); e nº 1 (inicial, inapagável), — numa limpeza radical, tresloucada, porém ainda com resultados frustrantes.

O snapshot nº 258 só foi descoberto, quase por acaso, ao revisar a documentação de referência sobre o assunto (ver abaixo), — na dica “Deleting unreferenced snapshots”, sob o item 3.5.4 - Deleting snapshots.

Como o usuário não tem acesso à pasta (oculta) /.snapshots, ele só pôde ser examinado no Midnight-Commander, aberto pelo Root.

Por algum motivo, falta um arquivo XML com os meta-dados, — ou faltam os meta-dados no arquivo XML, — e o Snapper não “vê” aquele snapshot.

Snapshot nº 258 na Listagem, 2 dias depois, — mas não na Tabela (ver Imagens anteriores)

O snapshot nº 258 não aparece em nenhuma das tabelas geradas pelo comando snapper -ls, — usadas, até então, como guia para deletar pares de snapshots. — Só aparece (desde aquela época) em comandos de listagem de pastas / arquivos, como ls /.snapshots -al:

flavio@Linux5:~> su
Senha:
Linux5:/home/flavio # ls /.snapshots -al
total 4
drwxr-x--- 1 root root  54 Jul  3 08:01 .
drwxr-xr-x 1 root root 166 Jan 17  2017 ..
drwxr-xr-x 1 root root  32 Jan 17  2017 1
drwxr-xr-x 1 root root  16 Jun  7 21:03 258
drwxr-xr-x 1 root root  66 Jul  1 00:29 302
drwxr-xr-x 1 root root  98 Jul  1 00:29 303
-rw-r----- 1 root root 408 Jul  3 08:01 grub-snapshot.cfg

Linux5:/.snapshots # cd /.snapshots
Linux5:/.snapshots # du -sh 1
7,0G    1
Linux5:/.snapshots # du -sh 258
6,2G    258
Linux5:/.snapshots # du -sh 302
6,2G    302
Linux5:/.snapshots # du -sh 303
6,2G    303
Linux5:/.snapshots # du -sh grub-snapshot.cfg
4,0K    grub-snapshot.cfg

Obs.: - Por princípio, os tamanhos indicados pelo comando du -sh [number] não se somam aritmeticamente, — pois há repetições, no caso dos pares “pre / post” (antes e depois de cada atualização ou instalação). — Note que a soma ultrapassaria os 25 GiB da partição.

A propósito:

flavio@Linux5:~> du --help

Summarize disk usage of the set of FILEs, recursively for directories.

Mandatory arguments to long options are mandatory for short options too.
  -h, --human-readable  print sizes in human readable format (e.g., 1K 234M 2G)
  -s, --summarize       display only a total for each argument

Barra de progresso empacada e nenhuma atividade de CPU, — 18 minutos após concluir a atualização

Assim, foi possível identificar sua data de 7 Jun. 2017, às 21:03.

Trata-se de uma atualização que parecia empacada. — Aliás, tudo empacou naquela sessão. — O carregamento do openSUSE demorou quase 2 minutos. — A manutenção programada do BtrFS começou logo após o início da atualização (download), — e tudo ficou devagar, quase travando.

O arquivo /var/log/zypp/history indica que os 3 pacotes da atualização foram instalados com sucesso, em apenas 4m 30s, — completados meio minuto antes das 21:03, — mas a barra de progresso continuou empacada na metade do caminho por mais 26 minutos (sem nenhum indício de atividade de CPU no Conky ou no KSysguard), — e às 21:29 reiniciei o sistema. — O novo boot demorou cerca de 3m30s; e um reload do atualizador indicou que estava tudo atualizado.

Nota: - Talvez fosse interessante “afastar” (no tempo) os agendamentos do Notificador de atualizações e da Manutenção BtrFS, — para evitar encavalamento. — É verdade que, uma vez adquirida consciência disso, bastaria não autorizar as atualizações, até ter certeza de que a Manutenção não irá começar. Mas, sem saber quantos minutos esperar, como ter certeza?

Fato é que, após 6 meses, ainda não encontrei a configuração desses 2 agendamentos, no YaST2. — Resta ir à luta no Google, — e ter sorte de adivinhar as palavras-chave corretas.

Por outros motivos, — monitorar o tempo de Boot e o uso inicial de Memória RAM, — também seria interessante afastar ambos agendamentos para 10 minutos uptime, pelo menos.

Deletando “unreferenced snapshot” no openSUSE

Para deletar o snapshot nº 258 (agora), foram usados esses 2 comandos:

# btrfs subvolume delete /.snapshots/258/snapshot
Delete subvolume (no-commit): '/.snapshots/258/snapshot'

# rm -rf /.snapshots/258

Ou seja, — primeiro, deletar o “subvolume btrfs”; depois, o diretório. — Nada de apenas deletar a “pasta” pelo Midnight-Commander.

Com isso, o espaço usado desabou de 14,5 GiB para 8,31 GiB, — o menor tamanho, desde 11 Fev. 2017 (quando a instalação do “freshplayerplugin” elevou a marca de 8,29 para 8,35 GiB). — Uma redução espantosa, de 6,19 GiB, numa tacada só.

Depois disso, pode-se dizer que voltei a ter fé na Humanidade, — onde se incluem os desenvolvedores e colaboradores do Snapper.


Leap e Tumbleweed - Cronologia


Avanços obtidos com Leap (BtrFS) e Tumbleweed (ext4), no conjunto de sistemas Linux instalados

Na prática, as coisas se passaram com mais cautela do que pode parecer, pelo relato acima:

1) openSUSE Leap 42.2 foi usado regularmente por quase 5 meses, — ainda com folga suficiente, — antes do uso de espaço em disco se tornar alarmante.

2) KDE-PIM, Baloo, Akonadi foram desinstalados após longa observação, — já na fase de “ajuste fino”, — com direito a erros e correções.

3) openSUSE Tumbleweed foi instalado quase 5 meses depois, — em outra partição, formato ext4 “tradicional” (sem risco de snapshots), — e serviu para mais alguns testes & ensaios que hesitava em arriscar no Leap.

4) openSUSE Tumbleweed foi usado para testar a instalação de ffmpeg, — tinha um receio meio supersticioso de que pudesse afetar a leveza com que o Leap enfrentava o recurso “Páginas” do Facebook, — embora o repositório Packman já estivesse habilitado (mas sem uso) no Leap.

5) Só no final, arrisquei o upgrade do Leap 42.2 para 42.3, — com o novo DVD gravado, pronto para reinstalar, no caso de não dar certo. — Não havia como fugir ao risco. A versão anterior ficará sem suporte 6 meses após o lançamento da nova. Se ficar, o bicho come.

17 Jan. 2017 - (Leap 42.2) - Instalado em partição BtrFS (sdb2).

17 Jan. 2017 - (Leap 42.2) - Após 27 minutos do primeiro Boot, havia instalado apenas o Conky + 5 dependências (704 KiB baixados; 2,24 MiB instalados). Estavam ocupados 5,37 GiB da partição-raiz (3:39).

26 Jan. 2017 - (Leap 42.2) - Usados 7,33 GiB da partição-raiz, ao dar por encerrada a fase inicial de configuração (20:17).

9 Jun. 2017 - (Leap 42.2) - Deletados pares de snapshots “não-importantes”, com redução do espaço usado de 14,1 GiB para 13,4 GiB (21:35 ~ 22:00).

2 Jul. 2017 - (Leap 42.2) - Removido KDE-PIM, Baloo e Akonadi. — Por falta de atenção, acabaram removidos também vários pacotes necessários, como Amarok, K3b, Kdepasswd, Kdialog, Kdnssd, Kget, Kfind, Konqueror etc., reinstalados em seguida (21:20 ~ 22:24).

3 Jul. 2017 - (Leap 42.2) - Deletados pares de snapshots “importantes”, exceto os 2 últimos, com redução do espaço usado na partição-raiz de 11,4 GiB para 9,99 GiB (8:00 ~ 8:05).

3 Jul. 2017 - (Tumbleweed) - Instalado em partição ext4 “tradicional” (sdd2), para teste e comparação (19:36 ~ 22:05).

29 Jul. 2017 - (Tumbleweed) - Removido KDE-PIM, Baloo e Akonadi. — Por falta de atenção, acabaram removidos também alguns pacotes necessários, como Digikam e Kgpg, reinstalados em seguida. — Entre uma coisa e outra, o arquivo ~/.xsession-errors acumulou 2.533 linhas, num total de 292 KiB (19:40 ~ 20:00).

3 Ago. 2017 - (Tumbleweed) - Habilitado repositório Packman e instalado ffmpeg (19:33).

3 ~ 4 Ago. 2017 - (Leap 42.2) - Upgrade para 42.3, usando uma “receita” simples de 3 comandos em tty1, enquanto continuava trabalhando normalmente em tty7 (22:38 ~ 0:26, conexão 1,3 MiB/s).

4 Ago. 2017 - (Leap 42.3) - Removido KDE-PIM, Baloo e Akonadi (1:36 ~ 1:56).

4 Ago. 2017 - (Leap 42.3) - Instalado ffmpeg (10:57).

__________
• Publicado inicialmente em 2 Ago. 2017, no openSUSE 42.2, e desenvolvido até 6 Ago. 2017 no openSUSE Leap 42.3.
• O registro de datas + horas facilita localizar Fotos e Capturas de tela, — além das anotações no “Caderno de informática”, — caso precise verificar mais algum detalhe.

— … ≠ • ≠ … —

openSUSE



Não-debians


Postado por Mboaba às quarta-feira, agosto 02, 2017 4 comentários
Marcadores: , , , ,

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


Postado por Mboaba às domingo, julho 10, 2016 4 comentários
Marcadores: , , , , , , , ,
Assinar: Postagens (Atom)