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”.
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 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.
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.
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:
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”.
Arch Linux KDE após instalação (gráfica) pelo Revenge Installer
O Arch Linux foi instalado de improviso, — sem estudo nem preparação, — como forma de começar a entender, na prática, o significado de todas aquelas explicações áridas e um tanto assustadoras do passo-a-passo ortodoxo.
Motivação, por assim dizer. — Muita gente começa a aprender um idioma, “falando” (como as crianças), para depois se interessar pelos “detalhes”, — mas pouca gente iria muito longe, se fosse convencida de que o único “método” é começar pelo estudo da gramática, flexões, declinações, análise sintática etc.
No caso do Arch Linux, essa inversão do “método ortodoxo” foi possibilitada pelo Revenge Installer, — um “instalador gráfico”, descoberto por acaso, num comentário em um Grupo Google.
Após 6 dias de uso contínuo do Arch Linux, no trabalho regular, as principais constatações são um pouco surpreendentes:
É uma delícia.
Funciona (e atende minhas necessidades principais) muito melhor do que o Debian, — que venho tentando dominar há mais de 8 anos, e que nunca pareceu tão “árduo”, e nem de longe “assustador”.
Instalar e usar o Manjaro, — e depois o Antergos, — não me havia feito avançar 1 milímetro, em direção ao Arch Linux. Neles não aprendi quase nada, que tenha sido útil nestes 6 dias. Nenhum deles “funcionou” tão bem, — nem atendeu tão bem às minhas necessidades principais, de uso cotidiano.
Está claro que ainda falta aprender quase tudo, — e conseguir instalar Google Earth, Wine etc., de uso menos frequente.
Estes 6 dias de trabalho no Arch Linux estão longe de significar um avanço espetacular, — mas, mesmo sem reler aquelas instruções “áridas” e assustadoras, elas agora fazem sentido. Tornaram-se compreensíveis e “lógicas”.
Vale observar que a instalação foi feita em uma partição “tradicional”, ext4, — e sem partição separada de /boot, — para não complicar o que não precisava ser complicado, nessa experiência inicial.
Índice
Download, gravação e boot
Particionamento
Configurações
Construção do sistema
Instalação, propriamente dita
Documentação e cronometragem
Grub, Grubs
Atualizações: Plasma Discover
Pacman
Pcurses
Discover, pcurses, pacman
Habilitando a partição Swap
Montagem automática de partições adicionais
Baloo_file, Akonadi, PIM
Limpeza do cache de pacotes
Quadro comparativo
Limpeza geral
Revenge Installer
Wallpaper [créditos]
Não-debians [Menu]
Download, gravação e boot
Verificação da imagem ISO do Revenge Installer
A imagem “revenge_installer-2017.03-x86_64.iso” foi baixada da página do Revenge Installer, e verificada por sha1sum e md5sum. (No dia seguinte, foi lançada nova revisão).
A mídia utilizada foi DVD, — gerado pelo K3b na menor velocidade disponível (4x), — para ter sempre à mão, pois também é uma “Live” de recuperação (recue disk).
Menu de Boot do Revenge Installer
A opção do Menu que interessava, neste caso, era “Boot Revenge Installer”.
Tela de boas-vindas ao Revenge Installer, — verificar conexão internet
O primeiro passo é certificar-se de ter uma conexão internet ativa (canto superior direito), — além de lembrar que é possível abrir um Terminal e usar a sessão Live como um CD de recuperação (Rescue).
As horas são indicadas em UTC, — e não vi como alterar isso, — mas é fácil traduzir em horário local (UTC-3).
De qualquer modo, não foram feitas Capturas de tela, — nem sei se existe esse recurso. — As fotos foram feitas por celular, com horário local nos dados Exif.
Recursos do Revenge Installer, no Desktop 2, durante a instalação pelo Desktop 1
Só bem mais tarde, — já na fase automática da instalação, propriamente dita, — lembrei de explorar o que mais havia por ali:
(a) Era possível configurar o Tema (canto superior direito), o que talvez facilitasse fotos mais nítidas; e
(b) A qualquer momento, é possível mudar da área de trabalho Desktop 1 para Desktop 2 (canto superior esquerdo).
Particionamento
Lembretes após optar pelo particionamento manual e selecionar a unidade (sdc)
O passo seguinte é optar entre particionamento automático, — que deleta todas as partições do HDD escolhido, — ou particionamento manual, para escolha das partições a serem usadas (caso já estejam prontas), com direito a todas as operações oferecidas pelo GParted (caso necessário).
Optei pelo particionamento manual, — foram apresentados os HDDs detectados (sda, sdb, sdc), — selecionei sdc.
Foi então avisado que, daí para frente, o instalador não formatará nenhuma partição, — para isso, deve-se clicar “Yes”, e usar o GParted.
Também lembra que o instalador suporta usar partições separadas de “/boot”, “/home” e Swap, — bem como Swap em arquivo dentro da partição raiz (“/”), se preferir.
Formatando as partições Linux9 e Home9 no GParted
Foram formatadas as partições Linux9 (sdc3) e Home9 (sdc7), — para eliminar até mesmo as configurações do Kubuntu Zesty Zapus, testado desde Outubro.
Pretendia usar também Swap9 (sdc11), mas não era necessário formatá-la.
A lista de partições
Descartei usar partição “/boot” separada; — escolhi a partição Root (“/”); — em seguida escolheria a partição (ou arquivo) Swap; — e por fim a partição “/home”.
Porém, ao exibir “todas” as partições, a lista terminava em sdc9, — e não existe botão de “Voltar”. — Só “Ok” ou “Cancelar”.
Analisando agora, com calma, fica claro que a lista incluía as partições estendidas dos 3 HDDs (sda4, sdb4, sdc4), — mas nenhuma partição com número lógico superior a 9. — Portanto, “Voltar” não resolveria nada.
De qualquer modo, Swap nunca foi problema crucial, numa instalação, — é até comum, mais tarde, ter de desabilitar um excesso de partições Swap, que diferentes instaladores selecionam sem perguntar.
Neste caso, bastaram 2 comandos, mais tarde, — “mkswap /dev/sdc11” + “swapon /dev/sdc11”, — e acrescentar 1 linha ao arquivo “/etc/fstab”.
Portanto, parece uma falha do instalador, — oferecer partições estendidas, e não detectar mais de 9 partições por HDD, — mas neste caso, felizmente, causou apenas a perda de 2 ou 3 minutos.
Configurações
As telas seguintes oferecem uma série de opções corriqueiras em qualquer instalação:
Idioma - pt_BR.UTF8
Teclado - br
País / Zona - America
Sub-zona - Sao_Paulo
Relógio do sistema - UTC (ou Local Time)
Hostname - Linux9
Usuário - [username]
Senha Root - •••••••••••• [repetir]
Senha de Usuário - ••••••• [repetir]
Construção do sistema
Opções de Kernel para o Arch Linux, no Revenge Installer
A partir daqui, o instalador oferece uma série de opções que significam a construção de um sistema personalizado, conforme as necessidades de cada usuário.
São oferecidos 4 tipos de Kernel, por exemplo, — corrente, LTS, de segurança, e “Zen” (?).
Seleção de interface gráfica para o Arch Linux, no Revenge Installer
Para abreviar o registro, vão em negrito as opções adotadas, — e listas longas são resumidas com “…”, omitindo outras, não-escolhidas.
Kernel
Linux
Linux-LTS
Linux-Grsec
Linux-Zen
Instalar suporte Yaourt para Arch User Repository (AUR) - Sim
Instalar suporte a impressora - Não
Ambiente gráfico
Plasma
Plasma-KDE-Applications
…
Internet
Chromium
Filezilla
…
Media
Gimp
VLC
…
Office
LibreOffice-fresh (?)
…
Utilitários
htop
GParted
…
Finalizar
Enquanto você não se escolher “Finalizar” (Finished), o botão “Ok” te leva sempre de volta a uma das Categorias acima, — você pode marcar e desmarcar os itens, quantas vezes quiser.
Instalar Bootloader - Sim
sda (Grub do Mageia)
sdb (Grub do Arch Linux)
sdc (Grub do openSUSE)
Clique “Yes” para começar a instalação, ou “No” para abortar.
Instalação, propriamente dita
Iniciar a instalação, de fato, do Arch Linux, pelo Revenge Installer
A 2ª parte do processo, — a “instalação”, propriamente dita, — é inteiramente automática, e se realizou em 41 minutos (13:21~14:02).
Desse tempo, os primeiros 11 minutos parecem ter sido de avaliação das fontes de software (mirrors) e, talvez, mais algum preparativo.
Os registros em /var/log/pacman.log indicam que foram instalados 1.054 pacotes em 30 minutos (13:32 ~ 14:02).
Documentação e cronometragem
Celular plugado (cabo USB), escolha a opção em minúsculas, — “gerenciador de arquivos”
O processo completo de instalação do Arch Linux, com KDE-applications e mais um punhado de aplicativos, — usando o Revenge Installer e uma conexão web de “10 megas” (1,3 MiB/s), — demorou 1h 30min (12:32 às 14:02).
A maior parte do tempo, — 49 minutos (12:32~13:21), — corresponde à fase inicial, de ações e opções determinadas manualmente pelo usuário:
• Particionamento manual
• Configurações
• Construção do sistema
O tempo gasto nessa primeira fase poderia ser dividido entre: (a) dúvidas de quem nunca lidou com Arch Linux; e (b) dificuldades de fotografar letras brancas em tela preta, com a janela do escritório fechada (devido ao sol da tarde).
As fotos de celular foram baixadas no Arch Linux KDE pelo Kamera.
Ao plugar o celular Nokia Lumia (WindowsPhone WP8) pelo cabo USB, escolha a opção totalmente em minúsculas, — abrir com o “gerenciador de arquivos”, — pois a outra jamais deu certo, em nenhuma das 12 distros (com KDE), experimentadas até hoje.
Selecione todas as fotos do celular que deseja baixar, — arraste-as para uma pasta no HDD, — e responda “Copiar” (que não afeta os arquivos de origem, no celular).
Umas 2 ou 3 vezes em que escolhi “Mover”, — implicando deletar as fotos no celular, após a cópia para o HDD, — isto causou danos à memória do smartphone.
Uso do KRename para renomear as fotos de celular para o padrão YYYY-MM-DD_HH-mm-SS
As fotos baixadas do celular Nokia Lumia WP8 foram, então, renomeadas (pelo KRename) para se adequarem ao padrão utilizado nos nomes-de-arquivo das Captura de tela, — de modo a se alinharem pela ordem cronológica.
O sufixo “_NL”, — de Nokia Lumia, — distingue-os de “M” (Mint) ou “MgA” (Mageia).
O padrão usado no KRename preserva qualquer “observação” que já tenha acrescentada ao final do antigo nome-de-arquivo, — da 16ª posição em diante (exceto “.extensão-de-arquivo”).
Levantamento das Fotos e Capturas de tela do download da ISO até o 1º Login do Arch Linux
As fotos da instalação, até o primeiro Login, — bem como as Capturas de tela, desde o download da ISO, até as atualizações / correções posteriores do Grub, — foram reunidas em uma pasta chamada “1_Instalacao”, cujo conteúdo foi listado para um arquivo TXT:
ls -1 > 1_instalacao.txt
Este arquivo “1_instalacao.txt” é a base para a cronologia do “Live Revenge Installer”.
Outro arquivo semelhante, — “2_instalado.txt”, com as Fotos e Capturas posteriores, reunidas em outra pasta, — permite levantar tudo o que foi feito desde o 1º Login no Arch Linux KDE.
Grub, Grubs
Correção manual do Grub do Mageia, para carregar o Arch Linux
Como o Grub de uso corrente pertence ao Mageia, era necessário atualizá-lo, — pelo comando “sudo update-grub”, — para reconhecer o Arch Linux KDE acabado de instalar em sdc3 (onde antes estava o Kubuntu Zesty Zapus).
Em seguida, foi aberto o arquivo “/boot/grub/grub.cfg” gerado pelo próprio Arch Linux, — para ver quais parâmetros ele usa para seu carregamento, — a fim de comparar com as entradas geradas pelo Mageia.
Infelizmente, não era possível usar “busca e troca global”, — pois afetaria as entradas para o Manjaro, — que precisam de substituição da mesmíssima string, porém com acréscimo de 2 Kernel diferentes:
Portanto, a busca & substituição teve de ser conduzida “caso a caso”, — examinar visualmente cada ocorrência, confirmar quando se tratava do Arch Linux, — mas introduzir uma das outras substituições, nos casos referentes ao Manjaro.
• Esta correção manual, — necessária após cada atualização do Grub (controlado pelo Mageia), — foi bastante simplificada, 6 dias depois, com a eliminação do Manjaro.
O primeiro, — e último, — Login manual no Arch Linux KDE
Depois, disso, o Grub, — gerado pelo Mageia, — carregou com sucesso o Arch Linux KDE, acabado de instalar.
O primeiro Login a gente nunca esquece, — em especial, se também foi o último Login manual. — Data e hora já se apresentam no fuso local (UTC-3).
Login automático em “Configurações do sistema → Inicialização e desligamento”
Dentro de 20 minutos, foi definido o Login automático, — nas “Configurações do sistema” (System settings) do KDE.
Quando há visitas que precisem usar o computador, prefiro desarmar o Login automático do Linux Mint KDE, — muito mais “amigável” para qualquer visita, — já devidamente “afinado”, e com 2 browsers (Firefox e Chromium), GoogleEarth etc.
Atualizações: Plasma Discover
Perda de tempo, — e uso abusivo de CPU, — com o Plasma Discover
No Arch Linux KDE acabado de instalar, o primeiro passo foi procurar o “notificador de atualizações”, para ver se o Menu de contexto (right-click) ofereceria algo como “recarregar” (reload) informações dos repositórios.
Não oferece. — As 2 únicas opções são “Ver Atualizações” e “Configurações das Atualizações”.
Por “Configurações”, entenda-se “criar atalho”, — nada mais.
E por “Ver Atualizações”, entenda-se “abrir o Plasma Discover”.
Jamais gostei do Muon Discover, — “lojinha multicolorida”, — mas, pelo menos, ele encontrava muitas coisas (nem tudo!), e não consumia CPU feito um desesperado. Não deixava o computador devagar-quase-travando.
Aqui, porém, o Plasma Discover “consome” CPU desvairadamente, causa “meia-trava” no computador, — e não encontra nada de útil. — Se candidata a ser a maior inutilidade jamais inventada.
Após 1 semana, esse “notificador” não se manifestou 1 única vez. — Só descobri atualizações, nos momentos em que lembrei de rodar o comando “sudo pacman -Syu”.
O Plasma Discover ainda não foi desinstalado, devido à possibilidade de que faça falta para alguns mecanismos do KDE, — como “Obter novos temas”, por exemplo. — Falta examinar com calma.
Nada a reclamar do Arch Linux, — nem do Revenge Installer, — por esse presente de grego.
Na hora de escolher Ambiente gráfico (“DE”, desktop environment), optei por “Plasma-KDE-Applications”, — em vez de apenas “Plasma”. — Fiz por merecer as vantagens e desvantagens decorrentes dessa decisão.
No 6º dia, foi instalado outro Arch Linux (em outra partição), — agora, usando o instalador gráfico Arch Anywhere, com a única opção de instalar um KDE “enxuto”. Então, criou-se a situação oposta, de precisar completar manualmente o KDE (ao invés de remover excessos). — Várias coisas ainda não funcionam: teclado PT-BR (ABNT2), login automático (SDDM) etc.
Pacman
Uso do pacman pelo método empírico, — saber o nome dos pacotes, — ou sonhar e jogar
A informação corrente é de que o Arch Linux não tem um “gerenciador de pacotes” (software) com interface gráfica, — embora possam ser usados alguns, que não são “oficiais”. — Pelo contrário, encoraja-se o usuário a usar o pacman, por linhas de comando em um Terminal.
Para um novato total, o problema de usar apenas comandos é descobrir os nomes dos pacotes existentes, — pois nem sempre são iguais aos que existem em outras distros.
Tinha de haver um modo mais inteligente de “procurar” aplicativos, do que sonhar com um nome, — e apostar no bicho, para ver se acerta a sorte grande, — ou procurar no Google, um pacote de cada vez, para compor o comando pacman.
Para não deixar que a brincadeira, logo de cara, já se transformasse num castigo, — “vá para o cantinho-do-estudo e só saia de lá depois de aprender tudo”, — foi praticado o tiro-ao-alvo-no-escuro, com razoável sucesso, nas horas restantes do primeiro dia.
Um comando “history | grep 'pacman' > history-pacman.txt” permite avaliar que houve nada menos que 10 acertos em 19 tentativas, — ou 10 em 17, se descontarmos 2 variações para tentar “cercar o bicho”:
Com isso, a brincadeira pôde avançar bastante, — tendo apenas o cuidado de não mexer com repositório AUR, por enquanto, para não escangalhar o brinquedo logo no primeiro dia.
O KRename, por exemplo, permitiu adiantar o levantamento das Fotos e Capturas de tela.
Também foram usados alguns comandos para documentar o estado do sistema, antes de descaracterizá-lo demais:
Todos esses arquivos TXT foram parar na “/home” do usuário, — exceto os gerados por “su”, que foram para “/root”, — de onde foram movidos, depois, para a pasta de registro dessa experiência.
Pcurses
Pesquisando pacotes de manipulação de imagens nos repositórios de software com pcurses
Embora instalado logo nas primeiras horas, o pcurses exigiu um pouco mais de leitura, antes de se tornar útil, naquilo que mais fazia falta, — pesquisar os pacotes existentes, para descobrir seus nomes.
O básico, para começar, é:
/ - para iniciar o campo de pesquisa /n:[string] - para pesquisar nos nomes dos pacotes [Enter] /c:[string] - para pesquisar nas descrições dos pacotes [Enter] /nc:[string] - para pesquisar nos nomes e nas descrições [Enter] → - para colocar um pacote na fila (Queue) Tab - para alternar entre a lista e o Queue ← - para remover um pacote da fila C - esvazia a fila r - recarrega informações dos pacotes c - limpa o campo de pesquisa h - Help (Referência rápida) q - sair do Pcurses (antes de fechar o Terminal)
kim4 encontrado no pcurses, filtrando pacotes com “menu” (contexto) na descrição
Por enquanto, evitei usá-lo para instalar os pacotes descobertos, — apenas “ver” os nomes, e em seguida instalar por comando, em outra janela do Terminal.
Assim, foram instalados mais 3 pacotes, necessários de imediato:
Menu de contexto adicionado ao Konqueror (e ao Dolphin) pelo kim4
O kim4, — já usado em outras distros (e esquecido na hora do tiro-ao-alvo), — permitiu converter as primeiras 227 Capturas de tela, do formato PNG para JPG, de uma tacada só, — ou seja, sem aquele limite de 200 arquivos, observado no KDE Neon em Setembro 2016.
Atualmente, o KDE Spectacle oferece opção de gravar as Capturas em diversos formatos, inclusive JPG. — O histórico no Github dá impressão de que isto apareceu em 15 de Abril. — Desabituado de usá-lo, ainda não havia percebido essa possibilidade em outras distros, nem percebi no primeiro dia com o Arch Linux.
Atalhos para Captura de tela pelo gnome-screenshot
E o gnome-screenshot permitiu substituir o KDE-Spectacle, — passando a gravar Capturas de tela sem notificação visual (dispensável).
Com o pcurses, portanto, tornou-se desnecessário procurar um “gerenciador de software com interface gráfica”.
Discover, pcurses, pacman
7 Jun. 2017 - Após 4 dias, — e sem receber nenhuma “notificação de atualizações” (Plasma Discover), — bastou esbarrar na tecla “1”, dentro do pcurses, para descobrir que havia, sim, 3 atualizações disponíveis.
Tal como veio, o arquivo “/etc/pcurses.conf” especifica alguns atalhos numéricos, — que o “pcurses -h” refere apenas genericamente, como “1 a 0”:
Além do “pcurses -h”, — pois não tive resultados com “man pcurses”, — vale a pena baixar os arquivos README e CONCEPT do GitHub.
Porém, depois de “aplicar” aquelas 3 atualizações indicadas pelo pcurses, disparei um comando “pacman -Syu”, — só por desconfiança, — e descobri que, na verdade, havia nada menos que outras 65 atualizações disponíveis.
Portanto, — a menos que todas aquelas 65 atualizações tenham surgido no curto intervalo de alguns minutos, — não convém se fiar muito, mesmo no pcurses.
Desmembrando a Ajuda do pacman por “capítulos” (operações)
Diante disso, procurei uma abordagem para começar a me familiarizar melhor com o pacman, item por item, sem submergir num caos de opções embaralhadas:
Arch Linux segundo KInfocenter, após upgrade e Restart
••• 8 Jun. 2017 - A hipótese de 65 pacotes atualizáveis surgidos de uma hora para outra não deve ser descartada sem exame.
No dia seguinte (8 Jun.), — ainda sem nenhuma notificação do Plasma Discover, — um comando “pacman -Syu” começou por fazer uma perguntinha boba. “Substituir wxgtk por extra/wxgtk2?”
Respondi que sim (sem exigir a presença de um advogado), e se apresentou um upgrade de 255 pacotes, — incluindo atualização de Kernel para linux-lts-4.9.31, — que levou 14 minutos (1,3 MiB/s).
Com isso, a “versão da Qt” passou de 5.8 para 5.9, os aplicativos passaram de 17.04.1-2 para 17.04.2-1, — e Gwenview deixou de fechar teclando Esc, embora a configuração desse atalho continue lá, e até tenha sido refeita. — Foi restabelecida sua função original (Modo de navegação), ainda não encontrada em parte alguma das configurações, para desabilitar.
Essa mudança de comportamento do Gwenview também ocorreu depois, no KDE Neon, após atualização dos aplicativos de 17.04.1 para 17.04.2, mantendo Qt 5.7.
Num primeiro momento, o painel Informações (F11) do Dolphin também parou de exibir visualização das imagens, — mas isso voltou a funcionar normalmente, após reiniciar (Restart), já com o Grub atualizado para o novo Kernel.
Habilitando a partição Swap
Criação da partição Swap e edição do arquivo /etc/fstab
Uma das poucas “falhas” observadas durante a instalação, é que o Revenge Installer não apresentou sdc11 entre as partições existentes, para selecionar como Swap.
De qualquer modo, criar, habilitar ou desabilitar partições Swap não é nenhum problema espinhoso.
A partição Swap foi habilitada mais tarde, — no Terminal, como root (“history” com outra numeração), — e a própria resposta do comando já forneceu o identificador UUID, a ser usado no arquivo /etc/fstab.
6 mkswap /dev/sdc11
7 swapon /dev/sdc11
Ainda sem encontrar “modo root” do Dolphin ou Krusader, acabei descobrindo que basta clicar no /etc/fstab pelo Dolphin-usuário, editar normalmente (como se fosse dono) e mandar salvar, — então, é pedida senha, e tudo é só alegria.
Ainda não tinha percebido essa facilidade, em outras distros. — Já vi não abrir, ou abrir mas não salvar — Falta verificar se isso está mudando [ver “Restrições ao modo root”, no Comparativo de sistemas].
Montagem automática de partições adicionais
Configurações do sistema → Dispositivos removíveis
Pelas configurações originais dessa instalação do Arch Linux, a montagem de partições adicionais, — clicando pelo Dolphin, por exemplo, — exigia senha.
Autorização para montagem de partições adicionais, sem pedir senha
Essa dificuldade não foi encontrada no Manjaro, — mas foi encontrada no Antergos, também baseado no Arch Linux. — Portanto, valia a pena verificar se a solução usada no Antergos resolveria a dificuldade aqui, também.
Em resumo, tratava-se de criar um arquivo “/etc/polkit-1/rules.d/99-udisks2.rules”, e colar nele o seguinte conteúdo, — para habilitar a montagem de partições sem a exigência da senha de Root:
// Allow udisks2 to mount devices without authentication
polkit.addRule(function(action, subject) {
if (action.id == "org.freedesktop.udisks2.filesystem-mount-system" || action.id == "org.freedesktop.udisks2.filesystem-mount" || action.id == "org.freedesktop.udisks2.filesystem-mount-system-internal") { return polkit.Result.YES; } });
Ainda sem encontrar “modo root” do Dolphin ou Krusader, o mais simples foi usar o openSUSE para fazer essa operação.
Início do Arch Linux com as partições adicionais montadas automaticamente
Depois disso, o Arch Linux finalmente carregou com todas as partições adicionais automaticamente montadas no início da sessão.
Com o Dolphin (3 abas), KSysguard, Xsensors, Conky, +20 partições montadas, — e já sem Baloo_file, — o sistema carregou em 44 segundos, ocupando 0,40 GiB RAM (segundo KSysguard) ou 565 MiB RAM (segundo o Conky).
Claro que essa alteração é um “quebra-galho”, — provavelmente, inaceitável para um administrador de sistema, do ponto de vista da segurança etc. — “Você que está em casa, nos assistindo, não tente fazer isto sem a supervisão de um adulto irresponsável”.
Baloo_file, Akonadi, PIM
Baloo_file fechou sozinho, ao desabilitar a “Pesquisa de Arquivos”
A única providência foi desabilitar a “Pesquisa de arquivos”:
Menu K → Configurações do sistema → Pesquisa → [_] Ativar a Pesquisa de arquivos
Imediatamente, o “baloo_file” desapareceu da Tabela de processos do KSysguard.
KOrganizer na Tabela de processos do KSysguard
Até o momento, a Tabela de processos do KSysguard não indicou atividade de nenhum banco de dados (MySQL, MariaDB), Akonadi ou PIM, — com exceção do “korgac” (KOrganizer).
Ao “Sair” do KOrganizer, — pelo Menu de contexto sobre as Notificações, — esse Processo também fecha e desaparece do KSysguard. Mas volta na sessão seguinte, a menos que seja desabilitado de vez.
Montagem de um comando para remoção do KDE-PIM
9 Jun. 2017 (0:11 ~ 1:08) - Praticando 1 hora de exercício de remoção do PIM, — pelo método construtivista / lapidador:
Filtrar por grupo (/g:kdepim), no pcurses
Examinar os pacotes
Copiar seus nomes para um “bloco de notas”
Montar o comando de remoção
Testar o comando de remoção
[while not “Ufa…!”]
Receber avisos sobre más consequências colaterais
Retirar do comando 1 ou 2 pacotes causadores de encrenca
Testar de novo o comando de remoção
[da capo]
Ufa…!
pacman -Rs [PIM packages] … Ufa!
A experiência demonstrou que o pacman é (pelo menos) tão inteligente quanto o apt, — e que é possível fazer todas essas operações de filtragem, exame, “montagem de comando”, teste, correção, aplicação final, — em uma fração desse tempo, pelo Synaptic.
Ainda que veja 1.000 páginas ensinando um comando, é sempre bom conferir o significado:
pacman -h -R
uso: pacman {-R --remove} [opções] <pacote(s)>
-s, --recursive remove as dependências desnecessárias
Devido ao método trabalhoso, a experiência ficou nisso, — 3 comandos “aprovados”, 56 pacotes removidos, — até descobrir se, por acaso, não haverá um “meta-pacote”, cuja remoção produza o “serviço completo”.
Não houve impacto no uso de recursos, — “baloo_file” (Pesquisa de arquivos) já estava desativado, e o resto não veio programado para entrar em operação sem ser chamado, — mas serviu para algumas coisas:
Ver como as coisas funcionam
Eliminar uma série de notificadores, gatilhos e menus
Reduzir as chances de “chamar” o PIM por distração
Limpeza do cache de pacotes
Limpeza do cache de pacotes desinstalados
Acostumado a simplesmente configurar o Synaptic para esvaziar o cache de pacotes baixados (após serem instalados), já estava incomodado de ver o Arch Linux, — um sistema “enxuto”, instalado 6 dias antes, e ainda quase sem acréscimos, — ocupar mais espaço do que o Kubuntu, com mais de 1 ano, e lotado de aplicativos.
O primeiro comando visa apenas otimizar as informações acumuladas sobre os pacotes, — agilizando o acesso à base de dados, verificação de dependências etc., — e não produziu nenhum efeito visível no espaço ocupado em disco:
# pacman-optimize
O segundo comando começa por eliminar informações de pacotes desinstalados, antes de otimizar, — e consta que não é isento de riscos, — mas liberou quase 1 GiB na partição do sistema:
# pacman -Sc && pacman-optimize
Nada que se diga, “esvaziou a partição”, mas é instrutivo saber o motivo de tanto espaço ocupado, — são guardadas sucessivas versões dos pacotes instalados, facilitando recuar de algum mau passo, — e ter uma ideia de como se pode fazer isso (ou limitar o número de versões guardadas), e assim por diante.
Quadro comparativo
Comparativo das funcionalidades já obtidas nos diversos sistemas Linux instalados
O Arch Linux KDE, — com o Chromium incorporado durante a instalação, — desde o primeiro instante mostrou incomum leveza, maciez e velocidade para navegar em “Páginas” do Facebook (não me refiro ao Feed, Perfis, Grupos).
Após 6 dias, ainda não “hesitou” sequer uma fração de segundo, a qualquer rolagem vertical, — nem sofreu um único momento de uso abusivo de CPU. — Enfrenta essa tarefa, melhor do que o Linux Mint 18 “Sarah” KDE; e a impressão subjetiva é de que enfrenta isso um pouco melhor, até, do que o Kubuntu ou o KDE Neon.
Ao mesmo tempo, ainda não deixou de exibir nenhum tipo de vídeo do Facebook ou do Youtube.
Como a navegação em “Páginas” do Facebook é necessária pelo menos 3 ou 4 vezes ao dia, — e nessas horas, é chato não poder assistir alguns dos vídeos que aparecem, — a galhardia demonstrada pelo Arch Linux + Chromium dispensa alternar para outra distro, durante vários dias seguidos.
Por comparação, o Manjaro, — depois de 5 meses, — segue no Grupo B, dos que só fazem uma coisa, ou só a outra.
Obs.: - Outros portais e sites conseguem, sim, provocar uso abusivo de CPU e causar lentidão no Chromium / Arch Linux. — No 4º dia, isto ocorreu ao visitar uma página do Estadão (O Estado de S. Paulo). Porém não tenho o hábito de visitá-lo, e bastou fechar aquela aba do Chromium. — Os sites 24/7 e Diário do Centro do Mundo (entre outros) também se vêm destacando como grandes consumidores de CPU, talvez pelo abuso de anúncios invasivos, porém não chegam a travar o Chromium durante longos segundos.
Wine e GoogleEarth parecem pedir um adiamento, até aprender mais, — mas, como são de uso menos frequente, justifica-se alternar para o Kubuntu ou Linux Mint, quando necessário.
Limpeza geral
Eliminação do Fedora, Manjaro, Antergos e Sabayon, com GParted no Knoppix
••• 8 Jun. 2017 - Os ótimos resultados obtidos no Arch Linux, — muito mais promissores do que os obtidos, até agora, no Manjaro e no Antergos (ponto de vista pessoal), — levaram a encerrar (por enquanto) a experiência com estes últimos.
Também foi encerrada a experiência com o Fedora, com o Sabayon, e com uma segunda instalação do Mageia (Mageia “B”).
Em resumo, foram formatadas 10 partições, — Raiz e Home dessas 5 instalações, — usando o GParted do Knoppix personalizado, com direito ao Chromium, para conferir as anotações.
Correção do Grub gerado pelo Mageia, para carregar o Arch Linux
A eliminação do Manjaro facilitou bastante a correção manual do Grub, — sob controle do Mageia (MBR do sda). — Agora, basta fazer uma substituição global para todas as entradas referentes ao Arch Linux, e outra para o KDE Neon.
Funcionalidades já obtidas nos sistemas Linux remanescentes
Com isso, fica mais fácil aprofundar o conhecimento dos 7 sistemas restantes, — bem como a manutenção e as configurações ainda não encontradas, — além de gastar menos tempo, a cada vez que um sistema recebe atualização de Kernel.
Revenge Installer
Enfrentar a instalação do Arch Linux, — ou a do TrueOS, — era tudo o que não estava no programa. Pelo menos, não em menos de 6 ou 12 meses, no mínimo.
No entanto, uma postagem de Swapnil Bhartiya, — Why you should run Arch Linux on your system, — recebeu um comentário com link para o projeto do Revenge Installer, cujo vídeo (acima) esclareceu mais do que todas as leituras explicativas, ilustradas por inúmeras Capturas de tela.
“A vila, diziam, tinha sido construída obedecendo a um engenhoso plano que compreendia o uso da maré para a limpeza das ruas. Com a enchente o arruamento alagava-se, e a vazante levava a sujeira para o mar, lavando as pedras” (O Retrato do Rei, Ana Miranda).
A imagem foi apenas rotacionada (-2,20°) no Gimp, para colocar na vertical as portas e janelas da parte central da foto. — Isso já tinha sido feito na sessão Live de reinstalação do Linux Mint 18 “Sarah” KDE (29 Abr. 2017).
Agora, a imagem foi cortada para restabelecer o formato retangular; redimensionada para 1024 pixels de altura; e as laterais cortadas (crop) em 1280 pixels de largura.
______________
Relato publicado inicialmente à 0:15 de 4 Jun. 2017 e desenvolvido até 7 Jun., no Arch Linux KDE.
••• Anotações adicionais em 8 Jun. 2017.
