Byteria: Escolhendo (e aprendendo) Linux conforme as necessidades

Aprendendo pela comparação de distros Linux e tentativas de obter desempenho similar

O que esse conjunto específico de distribuições Linux tem em comum (além do KDE) é certa “contemporaneidade”, — ou certa homogeneidade de repositórios, — independente das características próprias de cada uma.

Isto facilita “comparar” os diferentes sistemas, — e aprender um pouco mais, tentando levar todos ao maior grau possível de “usabilidade”.

Para “homogeneizar” os repositórios, foi necessário “apressar” algumas coisas, — transformar o Debian stable (Jessie) em testing (Stretch), desde Outubro 2016; — e substituir o Mageia 5 pelo Mageia 6 sta2, desde Maio 2017.

Com isso, eliminaram-se o Kernel 3.xx e o KDE 4.xx; — o Ksnapshot deu lugar ao KDE Spectacle como aplicativo-padrão; — a versão do Gnome-screenshot foi equalizada (com os recursos desejados); — e assim por diante.

Ao contrário do que poderia recear, versões em desenvolvimento, de teste, ou distros “rolling release”, não têm dado problema.

O Linux Mint “Sarah” Beta, por exemplo, foi o melhor “ambiente de produção” da série 18, — nem reinstalei após o lançamento. — Só “estragou” na migração para 18.1 “Serena”.

O KDE Neon, — instalado em Maio 2016, quando ainda nem se apresentava como uma “distribuição”, — também foi um dos sistemas mais “produtivos”, ao longo de 10 meses … até ser apagado, involuntariamente, num momento de distração. Acontece.

O que lamento, é não ter guardado aquelas imagens ISO do KDE Neon (Maio 2016), e do Mint 18 Beta (Agosto 2016), — usadas em Pendrive apagável, — ao passo que ainda guardo CDs do Kurumin de 2004.

Índice

Tempo de Boot e uso inicial de Memória RAM
Interferências agendadas
Reduzindo interferências
Conky vs. Htop
openSUSE
Mageia 6 sta2
Kernel
Google Earth (sem 3D)
Redes sociais
Observações
Não-debians [Menu]

Este relato é uma continuação de “Quadro comparativo dos sistemas Linux instalados (2016-2017)”, — onde foram abordadas diferenças e mudanças recentes no uso do Dolphin, Krusader, Kate / KWrite como Superusuário (“as root”).

O Knoppix, — Live Pendrive com Persistência, — não entra na comparação. É um ótimo conjunto de ferramentas de manutenção (com direito a Chromium sincronizado), mas incômodo para uso prolongado, quando se dispõe de apenas 4 GB RAM.

Tempo de Boot e uso inicial de Memória RAM

Tempo de carregamento (Boot) e uso inicial de Memória RAM nos Linux (configurados)

Isto não é uma comparação tecnicamente rigorosa, — apenas uma guia de pesquisa, para entender diferenças de comportamento, — e eventualmente obter, em um Linux, algo que outros mostram ser possível.

A essa altura, todas as distros já receberam um grande número de configurações personalizadas, — semelhantes, mas não 100% iguais.

A configuração de maior impacto é a remoção do conjunto de aplicativos que compõem o PIM, — Personal Information Manager, — mas parece provável que ainda fiquem resquícios.

O KDE Neon e o “Arch (b)” já vieram sem PIM, — portanto, não têm “resquícios” a eliminar, — e batem todos os outros, quanto ao menor uso inicial de Memória RAM, com exceção do Debian, que tem 1 diferença (adiante).

Também são desativados “Pesquisa de arquivos” (File search) e “Carteira do KDE” (Kwallet), além de outros serviços, como:

Notificador de mudança de URLs remotas
Atualização das pastas de pesquisa
Gerenciador de impressão
Servidor do Write (mensagens locais)
Touchpad

No Arch, não foi instalado suporte a impressora, — mas nos outros, ainda não foi desinstalado (caso exista), — exceto no Mageia, onde hplip se destacou à vista.

O tempo de Boot de cada sistema Linux é uma medida um tanto arbitrária, — o momento em que é exibida a área de trabalho completa, com Painel, wallpaper, e (em alguns casos) a notificação de que foi estabelecida a conexão web, — com alguma variação do “tempo humano de resposta”.

A medida de uso de Memória RAM tomada logo que o ambiente é carregado não é a mais correta, — pois ainda há bastante atividade de CPU, e só depois o uso de Memória RAM diminui, — até se estabilizar, após mais alguns segundos, caso não ocorra qualquer ação do usuário, nem acionamento automático de algum serviço agendado.

Interferências agendadas

Agendamento da verificação de atualizações no antigo Linux Mint 17.3 Cinnamon

No antigo Linux Mint Cinnamon (já removido), há tempos encontrei a configuração do tempo de espera (“20”) para a verificação de atualizações, após o início da sessão.

Agendamento da verificação de atualizações, no mintUpdate

Na atual instalação do Linux Mint 18 “Sarah” KDE, a verificação de atualizações está agendada para 10 minutos após o início da sessão, — e novamente a cada 2 horas, — por opção pessoal.

No Mageia, a configuração (original) é de verificar atualizações 5 minutos após o Boot e novamente a cada 3 horas.

No Debian, é comum o Painel já aparecer indicando atualizações, — dando a impressão de que a verificação foi feita durante o carregamento do sistema, — mas outras vezes isto só ocorre alguns minutos depois.

No openSUSE, a verificação de atualizações costuma ter início quase sem demora, logo após carregar a primeira sessão do dia.

unattended-upgrades menos de 3 minutos após carregar o Zesty Zapus

Ao que parece, todos eles apenas verificam, e avisam, — mas posso estar enganado.

No Kubuntu Zesty Zapus (já removido), atualizações “de segurança” ocorriam sem perguntar nem avisar nada, deixando o sistema extremamente lento, devagar-quase-travando (unattended-upgrades); e somente as demais eram notificadas no Painel.

Na instalação atual do KDE Neon (2017), “unattended-upgrades” não está instalado; e não existem registros de atividade anterior.

No Kubuntu 16.04 LTS, /var/log/unattended-upgrades registra atividade regular desde sua instalação, em Abril 2016, — porém nunca chamou atenção.

Na atual instalação do Linux Mint 18 “Sarah” KDE, os registros parecem repetir, — invariavelmente, — “Sem pacotes encontrados que podem ser atualizados sozinhos e sem dependendo de auto-remoções”.

Em princípio, imagino que todos ofereçam alguma possibilidade de configurar o momento de iniciar a verificação, — além da frequência etc., — mas isso ainda está para ser examinado.

Aqui, o importante era evitar atividades disparadas nos primeiros 3 minutos de carregamento, — para isolar eventuais distorções no uso de Memória RAM.

Manutenção do sistema de arquivos BtrFS, pouco após iniciar a sessão do openSUSE

No openSUSE, — único instalado com sistemas de arquivo não-tradicionais (BtrFS e XFS), — também é comum disparar manutenção, desfragmentação etc., provocando lentidão geral (quase travando), cerca de 10 minutos após o início da primeira sessão do dia.

Mas, há alguns registros dessa atividade, bem antes dos 10 minutos, — a descobrir por quê.

Reduzindo interferências

Para diminuir as diferenças introduzidas artificialmente, foram desabilitados alguns aplicativos que eram carregados automaticamente no início de cada sessão, — mas não por igual em todas as distros instaladas:

Dolphin - que era carregado automaticamente em todos os sistemas, porém com número desigual de abas (3~5), — e exibindo pastas muito diferentes, em cada Linux, — algumas com poucos arquivos, outras com centenas de arquivos
KSysguard - que era carregado em todos os Linux instalados
Xsensors - que era carregado em vários dos Linux
Psensor - que era carregado só em alguns sistemas

Persiste 1 diferença, cujo efeito não foi verificado: — Todos os sistemas carregam com 16 partições adicionais montadas automaticamente, pelo udisks2, — com exceção do Debian, onde a montagem automática de partições adicionais (ainda) é feita pelo /etc/fstab, usando os identificadores UUID.

Conky vs. Htop

Tempo de Boot e uso inicial de Memória RAM, segundo Conky e Htop

Para começar, foram feitos testes carregando automaticamente o Conky e o Htop, no início de cada sessão, — exceto no Linux Mint 18, onde não consegui.

Os números indicados pelo Conky e pelo Htop foram muito semelhantes, — com pequenas diferenças de ciclo de atualização, — exceto no openSUSE, onde apresentaram uma discrepância espantosa.

Naturalmente, a abertura automática do Htop / Konsole eleva o uso inicial de Memória RAM.

Forçar tamanho e posicionamento padronizado do Konsole (pelo Kwin), para não cobrir o Conky, também afetou os resultados obtidos, — mas isto só foi comprovado depois.

Os dados dessas experiências usando Conky + Htop foram mal-monitorados, nos casos do Kubuntu e do Linux Mint.

No Kubuntu, o Kwin não conseguiu forçar o posicionamento do Konsole, — o Htop abriu sempre sobreposto ao Conky, sendo necessário arrastá-lo manualmente em seguida, para uma segunda Captura de tela.

No Linux Mint, não cheguei a conseguir que o Htop fosse aberto automaticamente no início de cada sessão, — era necessário abrir o Konsole e chamar o Htop manualmente, em seguida. — Neste caso, os primeiros números não incluem o Htop / Konsole.

Nos 2 casos, estas ações foram realizadas logo após a primeira Captura de tela, — e só mais tarde foi constatado que o Gnome-screenshot costuma ocupar cerca de 25 MiB da Memória RAM, durante cerca de 21 segundos. — Portanto, os dados da segunda Captura estavam viciados. Era necessário um intervalo maior.

De qualquer modo, esse primeiro levantamento já foi suficiente para identificar as maiores demoras do Boot e alto consumo inicial de Memória RAM, — no openSUSE e no Mageia. — Algumas causas foram identificadas e, dentro do possível, eliminadas.

openSUSE

Uso inicial de Memória RAM diminui (Conky) / aumenta (Htop), — e se reduz a diferença entre eles

Somente no openSUSE, houve discrepância digna de nota, — Conky indicando uso de Memória RAM cerca de 100 MiB maior do que no Htop, no primeiro momento, — mas entender isso, é coisa que fica para o futuro.

Tal como nos demais, a atividade de CPU cai drasticamente, alguns segundos após o carregamento do sistema.

No openSUSE, porém, ocorre apenas uma leve redução na indicação de Memória RAM pelo Conky, — contra um leve aumento no uso indicado pelo Htop, — e a discrepância entre eles se reduz para 50 ~ 60 MiB.

Exceto, claro, quando se inicia uma verificação de atualizações, — ou uma manutenção do sistema de arquivos BtrFS, — coisas que costumam acontecer após o 1º Boot do dia.

uptime Conky   Htop

1m 26s   528   437 MiB - Forçar posição e tamanho do Konsole (Kwin)

1m 43s   549   448 MiB - Forçar posição e tamanho do Konsole (Kwin)
3m  0s   528   470 MiB
4m  0s   622   575 MiB - updates available

1m 28s         432 MiB - Livre posicionamento do Konsole
1m 34s   533   449 MiB - Konsole arrastado

1m 28s   537   437 MiB - única leitura

1m 25s   529   434 MiB - Livre posicionamento do Konsole
3m  0s   516   457 MiB
4m  0s   516   457 MiB

Principal candidato a ser causa da demora de Boot do openSUSE

Quanto ao tempo excessivo de carregamento do openSUSE, deve-se a um “start job is running for wicked managed network interfaces”, — com demora de 32 ~ 36 segundos, — e que também promete tomar algum tempo para solucionar (de preferência, sem provocar danos colaterais).

Mageia 6 sta2

Remoção do hplip no Mageia

Chamou atenção o alto uso inicial de Memória RAM pelo Mageia 6 sta2, — ainda não examinado em profundidade.

A remoção do suporte a impressora HP (hplip), — bem como a desativação de alguns serviços de segundo plano, — já permitiram alguma redução no uso inicial de Memória RAM.

Falhas de configuração de Virtual Console e início de Software RAID no Boot do Mageia

Também foi eliminada uma configuração de “ABNT2” para o console virtual, que dava mensagens de erro na inicialização (não afetou a acentuação no tty); — e desativado o monitoramento de RAID:

# systemctl disable mdmonitor.service

Eliminando configuração em /etc/vconsole.conf que gerava mensagem de erro no Boot

Essas duas configurações apenas eliminaram mensagens de erro durante o Boot, — sem efeitos visíveis no tempo de carregamento ou no uso inicial de Memória RAM:

uptime Conky   Htop

1m 17s   618   618 MiB

1m 17s   605   584 MiB
2m  0s   596   596 MiB
2m 30s   599   599 MiB
3m  0s   571     - MiB - fechado Htop

- fechados alguns serviços no System settings → Inicialização e desligamento
- removido hplip etc.

1m 20s   583   582 MiB
2m  0s   554   554 MiB
2m 38s   524     - MiB - fechado Htop
3m  0s   524     - MiB

- editado /etc/vconsole.conf (FONT e KEYMAP em branco, agora)

1m 15s   580   580 MiB
2m  0s   554   554 MiB
2m 30s   555   554 MiB
3m  0s   532     - MiB - fechado Htop
3m 30s   524     - MiB

- Konsole com acentuação completa, inclusive Left-Win
- tty com acentuação, exceto Left-Win, que volta ao KDE
- systemctl disable monitor-service

1m 11s   576   574 MiB
2m  0s   550   550 MiB
3m  0s   524     - MiB - fechado Htop

xxxxx

Kernel

No KDE Neon e no Linux Mint 18 “Sarah”, — ambos reinstalados, com problemas que antes não existiam, — o Kernel foi substituído por versões mais antigas, na tentativa de voltar aos bons tempos.

Nas 2 instalações do Arch Linux, optei por Kernel LTS. — Podia ter feito opções diferentes, para comparar, — mas as diferenças do KDE (completo ou básico) talvez ficassem menos nítidas.

Google Earth (sem 3D)

Não existe pressa em tentar essa façanha em sistemas ainda pouco conhecidos. — Por ser pouco usado, é suficiente tê-lo em 2 sistemas, — e carregar 1 deles, quando necessário.

São grandes as chances de conseguir instalar o GoogleEarth também no KDE Neon, — isso já foi feito, no ano passado, — mas prevalece a expectativa de reinstalar (ou “consertar”) o próprio KDE Neon, em busca da mesma qualidade de antes, e isso não estimula investir muito em povoá-lo de aplicativos, por enquanto.

Redes sociais

Nada menos que 4 sistemas, — KDE Neon, Kubuntu, Mint 18 “Sarah” e Arch Linux, — permitem enfrentar as redes sociais (em especial, “Páginas” do Facebook), 3 ou 4 vezes por dia, com direito aos vídeos, sem cair num atoleiro de abuso de CPU.

Outros 2, — Mageia e openSUSE, — também permitem isso, desde que não faça questão de assistir alguns vídeos. O dia até rende mais.

Assistir vídeos da web, — e não poder enfrentar as “Páginas” do Facebook, — não tem utilidade. É um velho problema no Debian, que nunca consegui solucionar.

Observações

Essa não é uma comparação “técnica” de distribuições Linux, — mas, apenas, o levantamento de algumas dificuldades enfrentadas por um usuário específico (leigo, 8 anos no Kubuntu), com um conjunto específico de tarefas, em um hardware limitado (E7300 Intel Core2 Duo 2,66 GHz video onboard, 4 GB).

São omitidas inúmeras outras tarefas, que não apresentam dificuldades, nem diferenças relevantes entre as distros instaladas.

A seleção seguiu critérios mutáveis, ao longo do tempo, — Kubuntu, Debian e Linux Mint há 8 anos; KDE Neon a partir de 2016; os demais, a partir de 2017, — começando pela capacidade de enfrentar a instalação (Arch por último, com instaladores gráficos) e filtrando as que apresentaram poucas perspectivas de uso pessoal (retirados Fedora, Manjaro, Antergos, Sabayon).

O objetivo é dispor de distros de “troncos” diferentes (não-Debian), — e de preferência, não-sujeitas a “decisões proprietárias”.

— … ≠ • ≠ … —

Byteria

Translate

quarta-feira, 14 de junho de 2017

Escolhendo (e aprendendo) Linux conforme as necessidades