Byteria

Artix Linux com KDE Plasma, OpenRC e XLibre

noreply@blogger.com (Mboaba) — Thu, 09 Apr 2026 20:44:00 +0000

Artix Linux com KDE Plasma, OpenRC e XLibre •

Há muito tempo, eu queria experimentar o Artix Linux — sem SystemD — para conferir a viabilidade de substituir o Arch Linux, dentro dos meus hábitos de trabalho no computador.

Como brinde, agora o Artix vem com XLibre — um fork do X11 com a perspectiva de atualizações de segurança — embora o usuário do KDE possa escolher sessão Plasma Wayland ao fazer Login.

Instalei o Artix em outra partição (dualboot), para experimentar pelo tempo que for necessário, antes de deletar (ou não) meu Arch. — Gostei do Artix, desde o primeiro dia, e quase não quero sair dele — mas ainda pretendo testar e aprender muito mais.

Índice

Download, sha256sum, K3b
xxxx
Capturas de tela
Flatpaks-fantasma

Download, sha256sum, K3b

Download e verificação da imagem ISO do Artix Linux

Minha intenção inicial era fazer a instalação por comandos, como fiz com o Arch (2019, 2020), mas a leitura das instruções para compor meu roteiro pessoal me desanimou. — Preciso fazer isso? Um dia, talvez, por diversão e aprendizado. Mas não, necessariamente, agora.

Vi que a Wiki do Artix desestimula esse esforço: — “A menos que você (...) esteja realizando uma instalação em servidor sem interface gráfica, há poucos motivos para usar as imagens básicas”. — Então, examinei as imagens ISO com KDE Plasma, e optei pelas “semanais” (não-testadas), que tinham sido lançadas naquele mesmo dia.

Escolhi OpenRC init, por ser mais “conhecido” e me parecer que tenha uma base maior de desenvolvedores e usuários (Gentoo). — Atualmente, já tenho o Void com Runit — e vejo falar menos do “dinit” e do “s6”.

Baixei a imagem “artix-plasma-openrc-20260407-x86_64.iso” da página de downloads do Artix — fiz a verificação pelo “sha256sum” — e “queimei” pelo K3b em DVD, para guardar.

O download direto prometia durar horas, pois não há espelhos no Brasil. — Baixei por Torrent, em cerca de 1 minuto.

Configuração do Fuso Horário, Teclado, Localização da sessão Live

No menu de boot, alterei o Fuso Horário para BRT, o Teclado para ABNT2, o Idioma / Localização para Reino Unido (en_UK) — e a sessão Live já começou com o horário correto: 12:05.

$ whoami
artix

$ echo $XDG_SESSION_TYPE
x11

$ history
    5  2026-04-07_12-12-52 sudo pacman -Sy
    7  2026-04-07_12-18-10 sudo pacman -S gnome-screenshot
    9  2026-04-07_12-37-16 echo $XDG_SESSION_TYPE
   11  2026-04-07_12-38-50 sudo pacman -S conky
   13  2026-04-07_12-53-48 echo 'export HISTTIMEFORMAT="%F_%H-%M-%S "' >> ~/.bashrc
   14  2026-04-07_12-54-03 source ~/.bashrc
   15  2026-04-07_12-54-08 history

A sessão Live já começou em XLibre (identificado como X11) — o que foi ótimo, para poder usar o “gnome-screenshot” e o Conky.

Não encontrei a senha do Live User (artix) — mas o “sudo” nem pediu.

Instalei o “gnome-screenshot”, o Conky — configurei os atalhos para salvar as capturas em um Pendrive de 2 GB — e pude documentar tudo desde o início:

Configuração do gnome-screenshot para documentar a sessão Live

Trouxe uma configuração do Conky que tenho no Pendrive — movi para o Pendrive os arquivos do ~/Desktop — e instalei fontes Verdana, mais legíveis e econômicas de espaço vertical.

Iniciando a instalação do Artix pelo Calamares

Ao abrir o instalador Calamares, fui avisado de que a opção “online” é experimental, e recomendado a usar a opção “offline”.

Ainda no “Welcome”, alterei o Idioma para Inglês britânico (en_UK). — Ao escolher o Fuso Horário BRT, não percebi que isto incluiria Números e Datas em Português do Brasil. — Se percebesse, teria insistido nos padrões britânicos.

xxxx

Capturas de tela

\\\\

xxxx

Flatpaks-fantasma

Remoção de Flatpaks herdados na partição /home

Eu tinha 9 flatpaks do sistema e 8 flatpaks do usuário, na distro que precedeu o Artix nas partições Linux11 e Home11. — Ao reaproveitar a pasta pessoal na Home11 (não formatada), meu 2º Conky indicou a sobrevivência de 8 flatpaks de usuário — informação do Fastfetch.

Conky (2) - before:

  ${execi 600 fastfetch | grep -o -P '.{0,0}Packages.{0,43}'}

Removing flatpaks:

  2026-04-10 - 14:20   # pacman -S flatpak
  2026-04-10 - 14:28   $ flatpak uninstall org.dupot.easyflatpak org.freedesktop.Platform org.freedesktop.Platform.GL.default org.freedesktop.Platform.GL.default org.freedesktop.Platform.VAAPI.Intel org.freedesktop.Platform.codecs-extra org.gnome.Platform org.gtk.Gtk3theme.Adwaita-dark
  2026-04-10 - 14:30   # pacman -Rns flatpak
  
Conky (2) - now:

  Packages: ${execi 600 pacman -Q | wc --lines} (pacman), ${execi 600 pacman -Qm | wc --lines} (AUR)

Para eliminá-los, instalei o Flatpak — usei seu comando “uninstall” — e tornei a remover o Flatpak.

Restou uma questão que eu vinha adiando há tempos: — Eliminar a dependência do Conky em relação ao Fastfetch, Neofetch etc. para extrair informações que podem ser obtidas diretamente.

E este caso mostrou uma lacuna do Fastfetch, que não indica o número de pacotes do AUR (Arch), do Pakman Essentials (openSUSE), ou do RPM Fusion (Fedora), por exemplo:

Distro      Fastfetch count

openSUSE    Packages: 4392 (rpm)
Arch        Packages: 1390 (pacman)
Debian      Packages: 3464 (dpkg)
Fedora      Packages: 3111 (rpm)
PCLinuxOS   Packages: 2381 (rpm), 13 (flatpak-system), 1 (flatp
PCLinuxOS   Packages: 2545 (rpm), 11 (flatpak-system), 8 (flatp
Mageia      Packages: 3493 (rpm)
Kubuntu     Packages: 2089 (dpkg)
Void        Packages: 1201 (xbps)
Mint        Packages: 2495 (dpkg)
PCLinuxOS   Packages: 2365 (rpm), 9 (flatpak-system), 8 (flatpa
Mx25        Packages: 2803 (dpkg)
Artix       Packages: 1076 (pacman), 8 (flatpak-user)

Alternativa para exibir também o número de pacotes do AUR, no Conky

Com 2 comandos — “pacman -Q” e “pacman -Qm” — obtive a contagem de pacotes nativos e do AUR, separadamente.

xxxx

___________________
• Publicado em 9 Abril 2026; e desenvolvido até...

— … ≠ “•” ≠ … —

PC desktop UEFI / GPT

MX Linux 25.1 KDE com SysVinit

noreply@blogger.com (Mboaba) — Tue, 20 Jan 2026 16:34:00 +0000

MX Linux 25.1 KDE (Infinity) com SysVinit •

As imagens ISO do MX Linux 25.1 voltaram a incluir SysVinit para o KDE Plasma — desde a versão “beta 1”. — Tratei de baixar e instalar.

Isto não é um “tutorial”. — É somente um registro do que eu fiz. — Ao revisar capturas e anotações para elaborar esse registro, encontro erros que na hora não percebi; e isso ajuda a entender e corrigir problemas. — Fico feliz se também for útil a outros colegas.

Eu uso poucos recursos — dos muitos que o MX Linux oferece — por isso, só vou falar dos que conheço.

Índice

Boot da sessão Live

Instalação do MX Linux

Instalando o Grub

Testando a instalação

Limpando as partições EFI

Links úteis

Boot da sessão Live

Opções de boot no Live MX Linux 25.1 KDE beta1 (Infinity) •

O Menu inicial do Live MX Linux 25.1 oferece um mundo de opções, antes de carregar a sessão. — Dá para passar uma tarde inteira explorando os recursos que existem ali. — Escolhi só alguns que já conheço e que sei que me interessam.

Em Opções avançadas >> Opções de Boot, marquei as opções de copiar o sistema para a Memória RAM; — usar horário UTC no relógio do PC; — e exibir menus de texto (que acabaram sendo supérfluos).

Opções do Live MX Linux 25.1 KDE beta1 (Infinity)

Em Idioma / Teclado / Fuso horário, selecionei Inglês da Irlanda (en_IE); teclado ABNT2; e horário BRT. — Em seguida, escolhi SysVinit para iniciar a sessão Live.

O “init” escolhido aqui será o do sistema instalado.

Mantive os padrões em todas as opções dos menus em texto

Os menus de texto repetiram as opções já feitas. — Aceitei todas, sem mudar mais nada.

Tela de boas-vindas do MX Linux 25.1

O aplicativo de boas-vindas oferece Instalador, FAQ, Manual do Usuário (já em destaque na Área de Trabalho), acesso à documentação (Wiki) e aos Fóruns (antiX, MX), Vídeos, Aplicativos Populares, Tour guiado.

Merecem especial atenção o MX Tweak, para configurações e ajustes rápidos; — o MX Tools, que oferece muitas ferramentas úteis; — e o lembrete das senhas demo e root.

O Quick System Info (no alto da tela) fornece as informações básicas para que os colegas do Fórum possam ajudá-lo em qualquer problema com seu hardware e / ou com o sistema operacional.

Instalação do MX Linux

Instalador do MX Linux 25, com instruções passo a passo

O Instalador do MX Linux 25.1 verifica a mídia de instalação e apresenta as instruções iniciais, na área principal da janela. — Do lado esquerdo, explicações detalhadas, ao longo de cada etapa do processo. — Embaixo, ainda é possível mudar a configuração do Teclado, se precisar.

Eu já estava na sessão Live há mais de 2 horas, configurando, fazendo anotações, capturando telas e examinando as imagens pelo visualizador “qimgv” (quase tão bom quanto o Gwenview). — Eu também tinha usado o GParted para criar uma partição para o MX Linux (sdb17, ext4, 30 GiB, label: Linux13); — e tinha instalado o Google Chrome, que acabei não usando (mas foi incluído na instalação final no PC).

As instruções do Instalador mandam fechar todos os outros aplicativos. — Mantive abertos o Dolphin, o Kate, o “qimgv” e o Konsole.

Siga as recomendações — para que a “persistência” funcione dentro do previsto.

Escolha do esquema de particionamento de disco

No “tipo de instalação”, optei por “personalizar o esquema de disco”, para usar (só) a partição que eu tinha criado. — Não me interessava apagar o SSD inteiro — nem substituir uma instalação existente.

Escolhi apenas uma partição, para instalar o MX Linux 25.1

Abri o menu suspenso da partição sdb17 (label: Linux13), e selecionei a barra “/” indicativa de partição-raiz. — O Instalador mudou o formato previsto para BtrFS — mas eu tornei a escolher ext4.

BtrFS é melhor para “instantâneos” (snapshots), que permitem “voltar atrás”, quando alguma coisa dá errado — mas isso exige mais espaço do que eu tinha (30 GiB). — Uso no openSUSE há 9 anos (nenhum problema até hoje!), mas mesmo com 50 GiB ainda fica apertado.

Antes de prosseguir, o Instalador advertiu que eu precisava selecionar uma partição EFI para montar em /boot/efi — senão, talvez eu não conseguisse inicializar a distro, depois de instalada.

O correto seria voltar, e fazer isso.

... mas perguntou se eu queria prosseguir. — Portanto, deu liberdade de escolha. — Decidi correr o risco.

Instalador avisa que a partição pode falhar em futuro próximo

17:36 (a) - O Instalador avisa que vai formatar a partição sdb17. — Essa informação deve ser conferida com muita atenção, pois se houver algum erro na lista das partições a serem formatadas, será impossível recuperá-las depois. — Se necessário, volte atrás e corrija.

17:36 (b) - Mandei prosseguir, e o Instalador deu mais um aviso: — A partição que escolhi tem 5 setores realocados. — Passou no teste, mas oferece risco de falhas em futuro próximo. — Recomendou interromper a instalação e usar o GSmartControl para um exame detalhado.

Resolvi prosseguir — por minha conta e risco.

Escolha da partição para instalar o Grub do MX Linux 25.1

Ao fechar o aviso, vi que o Instalador aguardava decisões: — Instalar o Grub? — “Local” para instalar o Grub. — “Partição” para instalar o Grub.

(O resto da instalação tinha ocorrido entre 17:36 e 17:37; — e pausou para aguardar essas decisões sobre o Grub).

Sim, eu queria instalar o Grub — a parte que fica em /boot/grub, na partição-raiz. — Mas o “local” (ESP) e a “partição” que ele pedia, dependiam de uma outra coisa, que eu não tinha feito, na etapa do particionamento: — Eu não tinha indicado uma partição EFI (ESP), para ser montada em /boot/efi.

O correto seria voltar atrás e escolher uma partição EFI.

Opções de Swap no Instalador do MX Linux 25.1

A seguir, o Instalador ofereceu opções de Swap. — A única opção marcada era “Criar um arquivo Swap” (swap file), pois eu não tinha selecionado minha partição Swap. — Desmarquei a criação do arquivo.

Rede, Localização e Serviços, no Instalador do MX Linux 25.1

Na tela seguinte, pediu as opções de Rede, tais como o nome do PC, o domínio — e servidor Samba (que dispensei). — Tive de escolher um “domínio”, mesmo que fictício.

Em seguida, nova chance de escolher a Localização Regional (Idioma), Fuso horário, Relógio, o formato das horas (12 ou 24h) — e uma opção “avançada” de serviços a serem iniciados automaticamente:

Serviços a serem iniciados automaticamente no MX Linux 25.1

Deixei habilitados os serviços que sei que vou usar — além dos que não tenho certeza. — Desabilitei só o bluetooth e o CUPS, que tenho certeza de que não vou usar.

Configuração do Usuário, senha, Login automático

O Instalador pediu o apelido a ser usado para Login do Usuário — será o nome de sua pasta pessoal — e sua senha.

Eu uso sempre o mesmo apelido (ID) — para reaproveitar as pastas pessoais de instalações anteriores.

O MX Linux não costuma habilitar a conta de “super-usuário” (root), mas você tem a liberdade de criá-la. — Já me acostumei a usar o sudo nas distros derivadas do Debian. — Fazer diferente, em uma delas, me deixaria em dúvida na hora de digitar os comandos.

Não tenho opinião sobre isso. — Em distros não-Debian, uso a conta root regularmente.

Habilitei o Login automático (Autologin) — e “Salvar as mudanças feitas na sessão Live”, para não ter de fazer de novo as mesmas configurações, depois de instalado.

Isso inclui arquivos salvos até o início da instalação efetiva em disco. — Arquivos salvos ou modificados depois disso precisam ser copiados manualmente, antes de encerrar a sessão Live.

Falha na instalação do Grub

Quando cliquei para prosseguir, o Instalador mostrou uma mensagem em letras garrafais dizendo que não conseguiu instalar o Grub.

Sugeriu reiniciar a sessão Live e usar o “Grub Rescue” para “consertar a instalação” — sinal de que só faltou o Grub.

Por que ignorei os avisos do Instalador? — Porque outros instaladores também reclamam, mas geram o arquivo interno de configuração /boot/grub/grub.cfg — mesmo que você não indique uma partição EFI para instalar nela o “bootloader” externo.

O Instalador do MX Linux 25.1 está certo. — O boot precisa dessas 2 coisas. — Querer só 1 delas é exceção.

Instalando o Grub

Eu não fazia questão do /boot/efi — mas precisava do /boot/grub/grub.cfg

Assim que fechei o Instalador, não encontrei mais a partição “Linux13”. — Pelo lsblk, vi que o rótulo da partição-raiz tinha sido alterado. — Agora, chamava-se “rootMX25”.

Montei em /mnt, pelo comando mount, e pude examinar a situação pelo Dolphin. — Faltava o arquivo /boot/grub/grub.cfg.

$ lsblk -o name,mountpoint,label,fstype,size | grep sdb17
└─sdb17                      rootMX25  ext4        30G

$ sudo mount /dev/sdb17 /mnt

$ lsblk -o name,mountpoint,label,fstype,size | grep sdb17
└─sdb17 /mnt                 rootMX25  ext4        30G

Chroot Rescue Scan: — Nunca foi tão fácil recuperar uma instalação

Abri o “Chroot Rescue Scan”, que permite “entrar na pele” de uma distro para executar comandos de recuperação. — Ele encontrou todas as distros instaladas no PC, inclusive o antigo MX-23 e o novo MX-25.

Fazer chroot manualmente é chato. — Com esse aplicativo do MX Linux, é um passeio no parque!

“Entrei” no MX Linux 25 (o termo é “visitar”), recém-instalado. — O prompt muda de “$” para “chroot>”:

Gerando o arquivo /boot/grub/grub.cfg no recém-instalado MX Linux 25.1

Executei uma “atualização do Grub”. — Gosto de usar o comando “real” (em vez do “alias” update-grub), para nunca esquecer o que ele faz. — Trata-se de gerar o arquivo /boot/grub/grub.cfg:

chroot> grub-mkconfig -o /boot/grub/grub.cfg
Generating grub configuration file ...
Found theme: /boot/grub/themes/mx_linux/theme.txt
Found linux image: /boot/vmlinuz-6.12.63+deb13-amd64
Found initrd image: /boot/initrd.img-6.12.63+deb13-amd64
Found Arch Linux (rolling) on /dev/sda3
Found Debian GNU/Linux forky/sid on /dev/sda4
Found Fedora Linux 43 (KDE Plasma Desktop Edition) on /dev/sda5
Found PCLinuxOS on /dev/sda6
Found PCLinuxOS on /dev/sda7
Found Mageia 10 (10) on /dev/sdb1
Found Ubuntu 24.04.3 LTS (24.04) on /dev/sdb2
Found Void Linux on /dev/sdb3
Found Linux Mint 22.3 Zena (22.3) on /dev/sdb4
Found PCLinuxOS on /dev/sdb5
Found MX 23.6 Libretto (23.6) on /dev/sdb6
Adding boot menu entry for EFI firmware configuration
done

Ele gerou “entradas” para outras distros — mas o importante é que gerou “entradas” para ele mesmo. — Agora, o Grub do openSUSE já pode ler esse arquivo e obter os dados para carregar o MX Linux 25.1.

Observe que ele não encontrou o openSUSE. — É comum, o Grub de algumas distros não detectar o openSUSE, instalado em uma partição BtrFS com “instantâneos” do Snapper (shapshots). — É por isso que escolhi o Grub do openSUSE para ser meu “Menu de Inicialização” (UEFI / GPT; Bios (legacy) / MBR) — e o do Mageia, meu “Grub de reserva”.

(É por isso, também, que até hoje eu evito instalar mais alguma distro em partição BtrFS com snapshots: — Isso complica meu dualboot / multiboot, em vários outros aspectos).

Grub do openSUSE, “atualizado” para detectar o MX Linux 25.1

Atualizei o Grub do openSUSE — ele detectou a nova instalação — e agora basta usá-lo, para carregar o MX Linux 25.1.

Testando a instalação

Montagem sem pedir senha — e sessão Plasma X11

19:20 a 21:20 - Testei a nova instalação durante umas 2 horas — ainda com a pasta /home criada dentro da partição-raiz. — Demorou um pouco, até conseguir Login automático em sessão X11 — e a montagem automática das demais partições.

Copiando do fstab do MX-23 as linhas das partições Home e Swap

Passei à fase seguinte da minha migração: — Abri o /etc/fstab do MX-23, copiei as linhas referentes às partições Home12 e Swap — e colei no arquivo /etc/fstab do MX Linux 25.1, pelo editor interno do Midnight Commander — “sudo mc”.

MX Linux 25.1 com a /home do antigo MX-23

21:20 a 0:00 - Ao reiniciar o MX Linux 25.1 (Plasma 6) com as configurações da partição /home do MX-23 (Plasma 5), encontrei as falhas normais nessa transição: — widgets (Weather, Moon) precisavam ser trocados por versões compatíveis; o lançador do System Settings precisava ser corrigido etc.

O Login automático caiu em sessão Plasma Wayland, com o Conky sem linhas ou gráficos — e as regras de janelas (KWin) bagunçadas. — Tornei a configurar o SDDM, e depois disso o Login automático passou a entrar sempre em sessão Plasma X11.

Lista dos pacotes instalados pelo usuário no MX-23

19 Jan. 2026 - 1:00 a 2:00 - Ainda carreguei duas sessões do antigo MX-23, para fazer uma última atualização do sistema (para registro); gerar um relatório “Quick System Info”; salvar uma lista dos meus aplicativos (User Installed Packages) etc. — além de listar todos os pacotes instalados — mas evitei mexer nas configurações, que eu já tinha começado a adaptar ao MX Linux 25.1.

Colando a partição Linux13 na partição Linux12

2:00 - Pelo GParted, copiei a partição do MX Linux 25.1 (sdb17) e “colei” na partição onde estava o MX-23 (sdb6). — Depois, deletei o original, para não ficar com partições duplicadas (e com o mesmo UUID). — Tornei a atualizar o Grub do openSUSE, para refletir a nova situação.

Desabilitando os-prober, quiet, splash no /etc/default/grub

20 Jan. 2026 - Desabilitei a detecção de outras distros (os-prober) pelo Grub do MX Linux 25.1. — Basta ele detectar a si mesmo, para que o Grub do openSUSE encontre as informações necessárias.

Aproveitei para desabilitar “quiet” e “splash”, para exibir tudo que acontece durante o boot — ao invés de uma animação bonitinha, que não dá nenhuma informação.

Essas 2 configurações ficam no arquivo /etc/default/grub — que editei pelo Midnight Commander (“sudo mc”, no Konsole). — Para fazer efeito, executei o “update-grub”, para gerar o /boot/grub/grub.cfg com as alterações.

Após eliminar 1 distro (MX-23) e reduzir o /boot/grub/grub.cfg do MX-25, o tempo de “atualização” do Grub do openSUSE caiu de 40’’ para 25’’ a 33’’. — Quanto mais distros, e quanto maior o “grub.cfg” de cada distro, mais tempo cada Grub gastará lendo os demais “grub.cfg”, a cada “atualização”. — Por isso, configurei as coisas para que cada Grub detecte apenas sua própria distro (gerando arquivos grub.cfg pequenos); e só o Grub do openSUSE (e o do Mageia, “reserva”) detectem as demais distros.

Limpando as partições EFI

Prioridade de Boot no utilitário da UEFI Bios da minha placa-mãe

23 Jan. 2026 - Dediquei umas 4 horas a testar e botar ordem nos bootloaders “externos”, nas minhas partições EFI (sda1) e EFI2 (sdb16) — e digo “externos” para distinguir do Grub que está “dentro” de uma distro. — Cada bootloader “externo” apenas indica um “dispositivo de inicialização”, controlado por uma distro.

O utilitário UEFI Bios da minha placa-mãe oferece um modo simples e fácil de definir a prioridade de Boot: — Basta escolher uma distro, do lado direito, e arrastá-la para o topo da pequena lista. — Como eu tenho mais de 4 distros, posso clicar em “Switch all”, e a lista se amplia para exibir até 7 ou 8, podendo rolar para ver outras mais embaixo.

Eu parei de usar esse recurso simples e fácil porque, depois de alguns meses, esse utilitário passou a congelar, sempre que clico numa distro e seguro para arrastar. — Desde então, utilizo o aplicativo efibootmgr em linha de comando (CLI), dentro de qualquer distro, para recolocar o openSUSE no topo (e o Mageia em 2º lugar), sempre que alguma atualização ou nova instalação coloca outra distro lá no alto:

# efibootmgr
BootCurrent: 0000
Timeout: 10 seconds
BootOrder: 0003,0000,0009,0006,0010,000D,0011,0013,0015,0002,0016,0001
Boot0000* opensuse      HD(1,GPT,329cbd71-80e8-43e9-a12c-126aac943cfa,0x800,0x400000)/\EFI\OPENSUSE\GRUBX64.EFI
Boot0001* debian        HD(1,GPT,329cbd71-80e8-43e9-a12c-126aac943cfa,0x800,0x400000)/\EFI\DEBIAN\SHIMX64.EFI
Boot0002* Ubuntu        HD(16,GPT,bae742e4-9473-4080-9046-c37e45c40b52,0x37d43800,0xff800)/\EFI\UBUNTU\SHIMX64.EFI
Boot0003* pclinuxos     HD(1,GPT,329cbd71-80e8-43e9-a12c-126aac943cfa,0x800,0x400000)/\EFI\PCLINUXOS\GRUBX64.EFI
Boot0006* arch_grub2    HD(1,GPT,329cbd71-80e8-43e9-a12c-126aac943cfa,0x800,0x400000)/\EFI\ARCH_GRUB2\GRUBX64.EFI
Boot0009* Mageia_grub   HD(16,GPT,bae742e4-9473-4080-9046-c37e45c40b52,0x37d43800,0xff800)/\EFI\MAGEIA_GRUB\GRUBX64.EFI
Boot000D* Void_grub     HD(16,GPT,bae742e4-9473-4080-9046-c37e45c40b52,0x37d43800,0xff800)/\EFI\VOID_GRUB\GRUBX64.EFI
Boot0010* MX_grub       HD(16,GPT,bae742e4-9473-4080-9046-c37e45c40b52,0x37d43800,0xff800)/\EFI\MX_GRUB\GRUBX64.EFI
Boot0011* Fedora        HD(1,GPT,329cbd71-80e8-43e9-a12c-126aac943cfa,0x800,0x400000)/\EFI\FEDORA\SHIM.EFI0000424f
Boot0013* Fedora        HD(16,GPT,bae742e4-9473-4080-9046-c37e45c40b52,0x37d43800,0xff800)/\EFI\FEDORA\SHIM.EFI0000424f
Boot0015* ubuntu        HD(1,GPT,329cbd71-80e8-43e9-a12c-126aac943cfa,0x800,0x400000)/\EFI\UBUNTU\SHIMX64.EFI0000424f
Boot0016* debian        HD(1,GPT,329cbd71-80e8-43e9-a12c-126aac943cfa,0x800,0x400000)/\EFI\DEBIAN\GRUBX64.EFI0000424f
#
# efibootmgr -o 0000,0009,0006,0010,000D,0011,0013,0015,0002,0016,0001,3
BootCurrent: 0000
Timeout: 10 seconds
BootOrder: 0000,0009,0006,0010,000D,0011,0013,0015,0002,0016,0001,0003
Boot0000* opensuse      HD(1,GPT,329cbd71-80e8-43e9-a12c-126aac943cfa,0x800,0x400000)/\EFI\OPENSUSE\GRUBX64.EFI
Boot0001* debian        HD(1,GPT,329cbd71-80e8-43e9-a12c-126aac943cfa,0x800,0x400000)/\EFI\DEBIAN\SHIMX64.EFI
Boot0002* Ubuntu        HD(16,GPT,bae742e4-9473-4080-9046-c37e45c40b52,0x37d43800,0xff800)/\EFI\UBUNTU\SHIMX64.EFI
Boot0003* pclinuxos     HD(1,GPT,329cbd71-80e8-43e9-a12c-126aac943cfa,0x800,0x400000)/\EFI\PCLINUXOS\GRUBX64.EFI
Boot0006* arch_grub2    HD(1,GPT,329cbd71-80e8-43e9-a12c-126aac943cfa,0x800,0x400000)/\EFI\ARCH_GRUB2\GRUBX64.EFI
Boot0009* Mageia_grub   HD(16,GPT,bae742e4-9473-4080-9046-c37e45c40b52,0x37d43800,0xff800)/\EFI\MAGEIA_GRUB\GRUBX64.EFI
Boot000D* Void_grub     HD(16,GPT,bae742e4-9473-4080-9046-c37e45c40b52,0x37d43800,0xff800)/\EFI\VOID_GRUB\GRUBX64.EFI
Boot0010* MX_grub       HD(16,GPT,bae742e4-9473-4080-9046-c37e45c40b52,0x37d43800,0xff800)/\EFI\MX_GRUB\GRUBX64.EFI
Boot0011* Fedora        HD(1,GPT,329cbd71-80e8-43e9-a12c-126aac943cfa,0x800,0x400000)/\EFI\FEDORA\SHIM.EFI0000424f
Boot0013* Fedora        HD(16,GPT,bae742e4-9473-4080-9046-c37e45c40b52,0x37d43800,0xff800)/\EFI\FEDORA\SHIM.EFI0000424f
Boot0015* ubuntu        HD(1,GPT,329cbd71-80e8-43e9-a12c-126aac943cfa,0x800,0x400000)/\EFI\UBUNTU\SHIMX64.EFI0000424f

Acima: - Um exemplo de 2 semanas antes, quando a instalação de um Kernel colocou o PCLinuxOS no topo das prioridades de Boot.

Boot Menu (F8), para escolher um bootloader qualquer

Para teste ocasional de algum bootloader, vou ao “Boot Menu”, pela tecla F8: — Basta usar as teclas (setas) para cima e para baixo, escolher uma distro, e finalizar com Enter. — Isso não altera a prioridade de boot nas inicializações seguintes.

Acima: - Dois bootloaders “Ubuntu”, com maiúscula (Kubuntu); e “ubuntu”, com minúscula (Mint) — além de uma instalação experimental do Fedora, já eliminada há meses, mas cujo bootloader continuava resistindo a todas as tentativas de removê-lo pelo efibootmgr.

Prioridade de Boot no modo Avançado do utilitário UEFI Bios

Enfim, posso alternar entre esse “modo EZ” e o “modo Avançado”, pela tecla F7 — mas ainda falta alguma coisa. — Talvez haja um modo de deletar bootloaders órfãos, mas até agora não consegui encontrar.

Em geral, tento deletar bootloaders inúteis pelo comando “efibootmgr” — mas às vezes eles continuam presentes na partição EFI ou na EFI2 — “visíveis”, ou “invisíveis” no utilitário UEFI Bios:

# history

  489  2026-01-23_13-23-28 efibootmgr
  490  2026-01-23_13-23-40 efibootmgr -b 10 -B
  491  2026-01-23_13-24-03 efibootmgr -b 13 -B

  495  2026-01-23_14-28-21 date; lsblk -o name,mountpoint,label,fstype,size,FSUSED,UUID
  496  2026-01-23_14-29-11 mount /dev/sdb16 /mnt

Foi o caso de um antigo bootloader “mageia” — que substituí em Abril 2025 por “Mageia_grub”, criado pelo comando “grub-install”. — A pasta ainda está lá, embora vazia:

Bootloaders eliminados pelo efibootmgr, ainda nas partições EFI

Para “ver” esses bootloaders persistentes, o jeito que encontrei é examinar minhas partições EFI (sda1) e EFI2 (sdb16) — pelo Dolphin (GUI) — ou por comandos (CLI), como o “tree”, por exemplo:

$ tree -U -L2 -D --timefmt '%Y %m %d' /boot/efi         $ tree -U -L2 -D --timefmt '%Y %m %d' /mnt

/boot/efi                      (/dev/sda1: EFI)         /mnt                    (/dev/sdb16: EFI2)

├── EFI                                                 ├── EFI
│   ├── 2020 01 10  -  pclinuxos                        │   ├── 2025 04 08  -  MX_grub       (*)
│   ├── 2025 07 22  -  boot                             │   ├── 2025 04 08  -  Mageia_grub
│   ├── 2020 01 12  -  opensuse                         │   ├── 2025 04 08  -  Void_grub
│   ├── 2025 07 13  -  ubuntu       (*)                 │   ├── 2025 07 13  -  BOOT
│   ├── 2025 12 23  -  fedora                           │   ├── 2025 03 13  -  fedora        (*)
│   ├── 2020 03 24  -  Debian                           │   ├── 2025 08 04  -  mageia        (*)
│   └── 2023 03 06  -  arch_grub2                       │   ├── 2025 07 13  -  ubuntu        (*)
├── System                                              │   └── 2025 12 28  -  pclinuxos
│   └── Library                                         ├── System
├── System Volume Information                           │   └── Library
└── mach_kernel                                         ├── System Volume Information
                                                        └── mach_kernel
12 directories, 1 file
                                                             13 directories, 1 file

Acima: - Editei as respostas do comando, deixando só as datas das pastas dos bootloaders, para facilitar a visualização.

Pude constatar que, embora o utilitário UEFI Bios e o comando “efibootmgr” mostrem um bootloader “Ubuntu” com maiúscula, lá nas partições EFI a pasta é “ubuntu” com minúscula. — O único modo de distinguir, é lembrando que o bootloader do Kubuntu é o da partição EFI2 (sdb16, no SSD WD Green); enquanto o do Mint é o da partição EFI (sda1, no SSD Kingston).

Deletando antigos bootloaders pelo Midnight Commander (mc) em modo root

Como último recurso de limpeza, abri o Midnight Commander como super-usuário (root) — e deletei as pastas dos bootloaders que não tinham mais nenhuma utilidade: — O 2º “fedora”, o “mageia”, e o “MX_grub” de Abril 2025, agora sem utilidade.

Configurando “Timeout” no Grub do Kubuntu

Ao testar todos os bootloaders, verifiquei que o Kubuntu e o Mint carregavam diretamente, sem exibir o menu do Grub. — Comentei (desabilitei) as linhas “GRUB_TIMEOUT_STYLE=hidden”; configurei o “GRUB_TIMEOUT=10”; e aproveitei para eliminar “quiet splash” em ambos. — Depois, “update-grub”, em ambos, para o Grub do openSUSE ler e incorporar essas mudanças.

A duplicidade de entradas para o Debian, no utilitário UEFI Bios e no efibootmgr, corresponde a 2 opções de Boot, dentro da mesma pasta: — “SHIMX64” e “GRUBX64”. — Não tenho (nem pretendo ter) Windows, e não uso Secure Boot. Vou deletar o “shim”, depois de ler mais um pouco sobre isso.

Depois de esclarecer todas as dúvidas e capinar o matagal de coisas sem utilidade, criei o bootloader para o MX Linux 25.1:

Pasted to /etc/fstab:

UUID=B7B0-A50B /boot/efi vfat noatime,dmask=0002,fmask=0113 0 0

$ sudo mkdir -p /boot/efi

$ sudo mount -all

$ sudo grub-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=Mx25_grub --recheck
Installing for x86_64-efi platform.
Installation finished. No error reported.

Fiz mais algumas anotações sobre isso no registro sobre o Fedora 42; e no registro da minha transição para UEFI-GPT.

Links úteis

Manual do Usuário do MX Linux 25

ISOs do MX-25.1 “Infinity” já disponíveis! - 19 Jan. 2026

Migração entre versões principais do MX

Site | Downloads | Forum | Wiki | Manuais

xxxx

___________________
• Publicado em 20 Janeiro 2026; e desenvolvido até...

— … ≠ “•” ≠ … —

MX Linux

PC desktop UEFI / GPT

PCLinuxOS Darkstar com KDE Plasma 6, dnf5 e SysVinit

noreply@blogger.com (Mboaba) — Thu, 25 Dec 2025 21:40:01 +0000

PCLinuxOS instalado pela imagem ISO KDE Darkstar 2025.09 •

Diferente de outras distros “rolling release” — que um dia substituíram o Plasma 5 pelo Plasma 6 em seus repositórios — o PCLinuxOS deixou cada usuário à vontade para experimentar o Plasma 6 e discutir problemas e soluções no fórum — ou continuar com o Plasma 5, acompanhar a experiência dos colegas, e migrar quando achasse conveniente.

Seção “kde6” adicionada aos repositórios do PCLinuxOS

Para isso, criou uma seção “kde6” em seus repositórios — ao lado das seções “kde5”, “mate”, “xfce4”, “kernel” etc. — Quando cada usuário decidisse fazer o upgrade, deveria trocar a seção “kde5” pela “kde6” (nunca, habilitar as 2 ao mesmo tempo!) — e seguir mais algumas instruções, nesta ordem:

Howto upgrade to Plasma 6:

apt-get update
apt-get dist-upgrade
apt-get install task-qt6

sd "kde5" "kde6" /etc/apt/sources.list
   ... or ...
   sed -i 's/kde5/kde6/g' /etc/apt/sources.list

apt-get update
apt-get install task-kde5-remove
apt-get install task-kde6-install
apt-get dist-upgrade
reboot

... and reinstall your favorite KDE applications

Portanto, não houve um “dia D”. — Não houve “anúncio”, nem “notas de lançamento”. — O que houve, foi um processo, com vários colegas e desenvolvedores fazendo testes e conversando no Fórum — entre Abril 2024 e Julho 2025.

E não foi notícia em parte alguma, que eu consiga encontrar.

Manual multilíngue do “InstallMe” / “MyLive Install” do PCLinuxOS, em PDF

Houve outras 2 novidades — uma, muito antes — e outra, logo depois:

(a) Desde 2023, as imagens ISO do PCLinuxOS já vinham com um novo instalador — o “InstallMe” / “MyLive Install” — em substituição ao antigo Draklive Install.

Adaptado do “17g-installer” — um fork do instalador do Linux Mint Debian Edition (LMDE), que substitui o Calamares.

Numa distro de atualização permanente (rolling release), não é comum “reinstalar”. — Por isso, muitos usuários ainda não conheciam.

Manual multilíngue do DNF Package Manager

(b) E desde Setembro 2025, as imagens ISO vêm com um novo gerenciador de pacotes — o DNF Package Manager (GUI).

O Synaptic continua nos repositórios (basta instalar) — e não há previsão de ser eliminado, a curto prazo. — Muitos usuários optaram por continuar com ele.

Essas 3 novidades acabaram se embolando, para alguns usuários.

Quem tinha instalado o PCLinuxOS antes de 2023, e agora optou por reinstalar, deparou-se com o novo instalador “InstallMe” / “MyLive Install” — e se reinstalou a partir de Setembro, deparou-se também com o DNF Package Manager (GUI).

Para complicar, um incêndio destruiu os servidores do site, do fórum, da wiki — e vários backups — apagando o acervo de conversas, dicas e orientações acumuladas no Fórum, ao longo daqueles meses.

Instalação antiga do PCLinuxOS, atualizada no final de 2025

Eis uma cronologia resumida — até onde pude recuperar informações no Wayback Machine (Internet Archive), no grupo do Facebook, e em outros sites e fóruns rastreados pelo Google:

Julho 2023 - Lançadas imagens ISO 2023.07 com o novo instalador “InstallMe” / “MyLive Install”, em substituição ao antigo Draklive Install.

Abril 2024 - Anúncio das últimas atualizações na seção “kde5” dos repositórios — KDE Plasma 5.27.11; Frameworks 5.115; Aplicativos KDE 23.08.5 — e o início da seção “kde6”.

Ainda houve mais algumas atualizações do KDE Plasma 5, até meados de 2025. — Não sei quando a seção “kde5” foi esvaziada, creio que no 2º semestre de 2025.

Outubro 2024 - Lançadas imagens ISO 2024.10 com as últimas atualizações da seção “kde5” — KDE Plasma 5.27.11; Frameworks 5.116; Qt 5.15.6.

As instalações existentes continuaram recebendo as demais atualizações de Kernel, bibliotecas, ferramentas, aplicativos. — Minha antiga instalação, por exemplo, com o KDE Plasma 5, continuou funcionando e recebendo as demais atualizações, até 29 Dezembro 2025 — quando fiz seu upgrade para o KDE Plasma 6.

Fevereiro a Junho 2025 - Colocados na seção “kde6” dos repositórios o KDE Plasma 6.3.2; o Frameworks 6.12, 6.13, 6.14; e os KDE Apps 25.04.1, 2, 3. — Não consegui encontrar lançamentos anteriores a esses, no Internet Archive.

23 Junho 2025 - Incêndio do prédio dos servidores do site, Fórum, Wiki etc. do PCLinuxOS, felizmente sem vítimas — mas com perda também de backups. — Isso dificulta recuperar a cronologia anterior, em detalhes.

Primeiras imagens ISO do PCLinuxOS com KDE Plasma 6

Julho 2025 - Lançamento das imagens ISO 2025.07, com KDE Plasma 6.4.3; Frameworks 6.16.0; Qt 6.8.2 — mas ainda com o Synaptic.

Agosto 2025 - Imagens ISO 2025.08.

Setembro 2025 - Imagens ISO 2025.09, com KDE Plasma 6.4.5; Frameworks 6.17.0; e Qt 6.8.2 — com o dnf5 (CLI) e o DNF Package Manager (GUI), em lugar do Synaptic — mas com toda infraestrutura do apt (apt-rpm), que permanece no controle das configurações.

Índice

Origens do PCLinuxOS

Gerenciamento de pacotes
Abundância de navegadores
Escala visual

Download e suporte
Boot e sessão Live
Instalação
Flatpak
Mountpoints
Mandrake, Conectiva, apt-rpm, Synaptic...

Origens do PCLinuxOS

Distros mais procuradas nas páginas do Distrowatch (2002-2009)

O PCLinuxOS foi lançado em 2003, com base na versão 9.2 do antigo Mandrake — então considerado uma das distros mais amigáveis para iniciantes no Linux. — Sua história foi contada na edição de Out. 2014 da PCLinuxOS Magazine.

Gerenciamento de pacotes

Ferramentas de gerenciamento de software no PCLinuxOS, em 2021 e 2025

Da brasileira Conectiva, o PCLinuxOS adotou o apt-rpm (CLI) e sua interface Synaptic (GUI).

Mandrake + Conectiva = Mandriva Linux

Agora, as novas imagens ISO já vêm com o DNF Package Manager, em vez do Synaptic — mas as configurações dos repositórios continuam em /etc/apt/sources.list.

O PClinuxOS mantém outras características incomuns — como o SysV init (em vez do SystemD) — e o gerenciamento separado, tanto do LibreOffice (que baixa direto da Document Foudation); quanto de Idiomas / Localização (addlocale).

Nos dois casos, pode-se instalar 1 idioma de cada vez. — Para instalar um 2º idioma, deve-se executar outra vez o gerenciador do LibreOffice e / ou o gerenciador de Localização; e assim por diante. — O idioma Inglês não pode ser removido do LibreOffice, nem do sistema.

Não encontrei mais o “Gerenciador de Localização” na seção “Software Center” do Menu, como acontecia em 2021. — Agora, ele está na seção “Configuração”, que oferece o PCLinuxOS Control Center (PCC), no topo, com o nome de “Configure o seu Computador”; e seus módulos individuais, na sequência — tal como o openSUSE fez com o YaST2.

Gerenciador de Localização oferece a Wiki enquanto aguardamos

Tanto o gerenciamento de Idioma / Localização (addlocale), quanto o do LibreOffice (e seus idiomas) precisam que o sistema esteja atualizado. — Se a gente esquecia, eles mandavam a gente fechá-los, atualizar tudo, e voltar depois.

Agora, o próprio “addlocale” fez a atualização do sistema, antes de instalar o Idioma / Localização que eu pedi. — Mas antes, solicitou que todos os “outros usuários” fizessem Logout, e que todos os aplicativos fossem fechados.

As regras são um tanto complexas. — Felizmente, agora o “addlocale” nos encaminha para sua documentação na “Wiki” — para a gente se divertir enquanto espera ele terminar o serviço.

Não sei se o Gerenciador do LibreOffice também atualizaria o sistema, pois o executei quando tudo mais já estava atualizado. — No fim, deixou 2 arquivos na minha pasta pessoal: — “getLOdictionary.txt” e “LibreOffice_Info.txt”.

Abundância de navegadores

Icecat — mais um navegador focado em segurança, em Fevereiro 2026

O PCLinuxOS também se destaca pela grande oferta de navegadores de internet. — Em 2023, a notícia do Distrowatch citava 26 opções. — Em 6 Jan. 2026, encontrei pelo menos 38 opções, nos repositórios:

# dnf search browser

 basilisk-browser            Basilisk is a free and Open Source XUL-based web browser
 brave-browser               Chromium based Brave Web Browser
 catalyst-browser            Catalyst Browser
 chromium-browser            Chromium Browser
 chromium-ungoogled-browser  Chromium Browser Ungoogled
 dillo-browser               Very fast and light web browser
 felida-browser              A lightweight Chromium Browser using Electron.js!
 fifo-browser                This is a privacy orientated browser.
 firedragon-browser          Garuda Firefox Browser
 floorp-browser              Floorp web browser
 ghostery-private-browser    Ghostery web browser
 iridium-browser             Iridium Browser
 mercury-browser             Firefox based browser for highend CPUs
 microsoft-edge-browser      Microsoft Edge browser for Linux
 midori-browser              Midori Web browser
 min-browser                 Min Browser
 opera-browser               Opera Web Browser
 otter-browser               Web browser controlled by the user, not vice-versa
 palemoon-browser-gtk2       Palemoon web browser
 palemoon-browser-gtk3       Palemoon web browser
 sidekick-browser            A productivity browser for focused work
 slimjet-browser             Slimjet Web Browser
 thorium-browser             Chromium based browser for highend CPUs
 tor-browser-bundle          Anonymous browser
 ulaa-browser                Ulaa Browser
 vivaldi-browser             Vivaldi browser
 waterfox-browser            Waterfox  web browser
 google-chrome-browser       Google Chrome
 librewolf-browser           A fork of Firefox, focused on privacy, security and freedom
 naver-whale-browser         Naver Whale Stable
 angelfish                   A modern mobile Web browser
 dooble                      Dooble Web Browser
 falkon                      Cross-platform Qt Web Browser based on QtWebEngine
 firefox                     Mozilla Firefox web browser
 konqueror                   KDE file and web browser
 links                       Lynx-like text WWW browser
 lynx                        Text based browser for the world wide web
 seamonkey                   Web browser, e-mail, news, IRC client, HTML editor
 (...)

Escala visual

Escala da tela e tamanho de fontes do Live PCLinuxOS, comparados a outra distro

Outra característica incomum, é que a sessão Live KDE Plasma vem com fontes 12pt, ao invés de 10pt como nas outras distros — e tudo, na tela, se apresenta 15% maior. — O Conky, por exemplo, que eu configuro com largura de 270 pixels, apareceu com 310 pixels.

Retornando de 110 para 96 dpi no PCLinuxOS

Para voltar à escala normal, bastou desmarcar a opção “Forçar Fonte DPI 110” — e fechar / reabrir os aplicativos, para voltarem ao padrão de 96 dpi; ou reiniciar o servidor X. — Com a janela do KDE System Settings já reduzida, aproveitei para configurar as fontes conforme as minhas outras distros, com Noto Sans e Hack 10pt e 8pt.

O System Settings não oferece essa opção no Wayland — mas o PCLinuxOS carregou sessão Plasma X11, automaticamente, em todas as sessões Live, e também depois de instalado. — Não tentei Wayland, que ainda não me interessa (só estou testando no Fedora).

Essa configuração aparece em ~/.config/xsettingsd/xsettingsd.conf, na linha “Gdk/UnscaledDPI” — mas editar só esse arquivo manualmente não faz efeito, pois ele é restaurado com o valor anterior, a cada novo Login. — Os valores são 96 x 1024 = 98304; ou 110 x 1024 = 112640:

# ls -n   [Home5]
total 8
drwxr-xr-x 35 1000 1000 4096 Mar  3 00:21 flavio
drwx------ 18 1000 1000 4096 Sep 22 12:22 flavio_OLD

# cat   [Home5]   /flavio/.config/xsettingsd/xsettingsd.conf | grep Unscale
Gdk/UnscaledDPI 98304

# cat   [Home5]   /flavio_OLD/.config/xsettingsd/xsettingsd.conf | grep Unscale
Gdk/UnscaledDPI 112640

# cat   [Home5]   /flavio_OLD/.config/xsettingsd/xsettingsd.conf
Net/CursorBlinkTime 1000
Net/CursorBlink 1
Net/SoundThemeName "ocean"
Gdk/UnscaledDPI 112640
Gdk/WindowScalingFactor 1
Net/ThemeName "Breeze"
Gtk/EnableAnimations 1
Gtk/DecorationLayout "icon:minimize,maximize,close"
Gtk/PrimaryButtonWarpsSlider 1
Gtk/ToolbarStyle 3
Gtk/MenuImages 1
Gtk/ButtonImages 1
Gtk/CursorThemeSize 24
Gtk/CursorThemeName "PolarCursorTheme"
Net/IconThemeName "breeze"
Gtk/FontName "Open Sans Semibold, Demi Bold 12"

Não investiguei além desse ponto. — Veja mais na Arch Wiki.

Download e suporte

Download e verificação da ISO pclinuxos64-kde-darkstar-2025.09, em Setembro

Baixei a ISO KDE Darkstar 2025.09, em 22 Set 2025 — verifiquei pelo md5sum — e “queimei” em DVD pelo K3b, para guardar.

A ISO “KDE Darkstar” é mais “enxuta” (minimal) do que a “KDE” (full), embora a diferença não seja espetacular.

Manuais do DNF Package Manager e do instalador do PCLinuxOS

Na página de download das imagens ISO, encontram-se também manuais multilíngues do “InstallMe” / “MyLive Install” — e do DNF Package Manager. — Vale a pena baixar, ler com atenção, e ter à mão para consultar, sempre que sentir necessidade.

Tudo isso também pode ser baixado dos outros 12 espelhos indicados no arquivo /etc/apt/sources.list — como o da Universidade de Princeton (EUA), ou o da UFPR (Brasil), por exemplo. — Torrents das imagens ISO estão disponíveis no Linux Tracker, incluindo algumas versões anteriores.

A Wiki (Knowledgebase) oferece bastante documentação — e no Fórum da distro, desenvolvedores e colegas mais experientes ajudam a tirar dúvidas e solucionar eventuais dificuldades, todos os dias.

Enfim, vale a pena acompanhar e colecionar a revista PCLinuxOS Magazine, que traz muitos artigos úteis — como DNF Package Manager (2025-10), Easy Flatpak Manager (2025-08), Recuperação dos sites (2025-08), Flatpak CLI commands (2023-07), Pacotes Flatpak e AppImage (2023-04), Uso do Timeshift (2020-12), História do PCLinuxOS (2014-10), por exemplo.

Boot e sessão Live

Boot do Live PCLinuxOS em “Copy to RAM” — e manter o Teclado dos EUA

No meu hardware (e usando Live DVD), a experiência mostrou que a melhor opção de Boot é “Copy to RAM” — e não mexer na opção-padrão de “Teclado dos EUA”, que é oferecida antes de carregar a sessão Live.

Nas primeiras tentativas de Boot, alterei o layout de Teclado, mas na tela seguinte já não havia texto nenhum, e não pude carregar a sessão Live. — Desde então, não mexi mais nisso, para não perder tempo — e desse modo também consegui, mais tarde, carregar sessões Live com as ISO 2024-10, 2025-07, e 2025-08, para examiná-las.

Mapa detalhado de seleção do Fuso Horário, na Live com KDE 6.4.5

Depois de carregar a sessão Live — aí, sim, alterei o layout de Teclado, fuso horário — e várias outras configurações.

Rodei várias sessões Live da ISO KDE Darkstar 2025-09, em Setembro, Novembro, Dezembro e Janeiro, para checar e documentar os detalhes — e a cada Live, fui configurando mais e mais, para facilitar o trabalho. — O gnome-screenshot, nas últimas sessões Live, me permitiu capturas bem melhores, mais fáceis e rápidas, do que o KDE Spectacle.

Tela da sessão Live com os ícones do “InstallMe” e seu manual (Help)

Minhas configurações nas sessões Live incluíram o Fuso Horário (para sincronizar fotos e capturas de tela); personalização do Dolphin, do Relógio etc.; instalação do Conky, gnome-screenshot, lm-sensors, Google Chrome, além do KRuler em Flatpak (para não atualizar todo o KDE); configuração do Teclado (ABNT2), atalhos, sensors, Conky etc.

Sucessivas instalações do PCLinuxOS

Com essas experiências, fiz 4 instalações sucessivas, em 2 partições separadas — vou chamar aqui “PCLinuxOS (2)” e “PCLinuxOS (3)” — sem afetar minha antiga instalação, feita em 2021:

---------------------------------------------------
Linux5 --> "PCLinuxOS (2)"                     sda6
--------------------------
$ stat -c'%w' /etc
2025-09-22 12:03:23            -- 1st installation

$ stat -c'%w' /etc
2025-11-25 15:23:17            -- 2nd installation
---------------------------------------------------
Linux6                                         sda7
------
$ stat -c'%w' /etc
2021-08-09 19:37:01            -- old installation
---------------------------------------------------
Linux11 --> "PCLinuxOS (3)"                    sdb5
---------------------------
$ stat -c'%w' /etc
2025-12-28 12:52:39            -- 3rd installation

$ stat -c'%w' /etc
2026-01-04 18:07:21            -- 4th installation
---------------------------------------------------

Afinal, minha antiga instalação estava funcionando bem, e eu não quis arriscá-la em um upgrade para o KDE Plasma 6, antes de ter uma nova instalação funcional. — Só no final de Dezembro, fiz o upgrade da minha instalação antiga.

Algumas situações, só consegui entender ou capturar em uma instalação, ou em outra — por isso, os exemplos e as imagens seguem uma ordem lógica — e não, cronológica.

Instalação

Escolhas do Fuso Horário, Idioma e Teclado no instalador do PCLinuxOS

Ao iniciar o “Install Me” / “MyLive Install” do PCLinuxOS, ele oferece mais uma possibilidade de configurações: — Escolhi Inglês britânico — além do Fuso Horário BRT e do Teclado em Português do Brasil (ABNT2).

No entanto, o manual do Instalador adverte:

O idioma especificado aqui é o usado pelo instalador — e não o idioma final do sistema operacional instalado. — O idioma instalado será o inglês [dos EUA]. Para adicionar um idioma diferente ao sistema, o script “addlocale” é necessário [...].

É proveitoso ler e reler o manual com atenção. — Ele não tenta apresentar o InstallMe / MyLive Install como algo perfeito. — Pelo contrário, indica suas falhas e deficiências.

Ele adverte, por exemplo, que marcar a opção de “baixar atualizações durante a instalação” pode causar longas demoras — pois o instalador usa o repositório do NLUUG, na Europa (Holanda) — que talvez não seja o mais adequado para o país onde você se encontra:

Escolha de “particionamento manual” e baixar atualizações

Escolhi "particionamento manual" — para (só) escolher as partições, que sempre preparo antes. — Na primeira instalação, por exemplo:

Device   Label     Mountpoint    Filesystem

sda1     EFI       /boot/efi     vfat
sda6     Linux5    /             ext4
sda12    Home5     /home         ext4
sda13    Swap      swap          swap

Clica-se com o botão direito do mouse em cada partição que se deseja usar — escolhe-se o ponto de montagem desejado — mas escolher um formato (mesmo que seja o existente) significa “Formatar”!

Particionamento manual — para escolher partições previamente preparadas

Tudo bem, formatar a partição onde se vai instalar o sistema — mas eu não queria formatar a partição “Home5”, pois eu queria aproveitar as configurações existentes na “pasta pessoal”, dentro dela, feitas na instalação anterior.

E... bah...! Não adianta escolher /dev/sda1 no campo que sugere instalar o bootloader, na parte de baixo. — É preciso selecionar explicitamente uma partição EFI (indicada como “Mac OS X”) — e escolher numa lista o ponto-de-montagem /boot/EFI.

Quanto ao botão “Edit partitions”, na parte de baixo, simplesmente abre o GParted — e desmarca todas as partições que você tiver configurado até esse momento. — Portanto, se vai usá-lo, faça isso antes de começar a escolher e configurar as partições.

Atribuí ao sistema o nome “Linux5”, criei a senha de Administrador (root), Usuário, ID etc. — e no final conferi o Resumo apresentado para confirmação, antes de iniciar a gravação em disco:

O instalador iria formatar minha antiga /home

Até aí, é possível voltar atrás (Back), para corrigir alguma coisa — ou sair do instalador (Quit) e abortar a instalação.

Na primeira instalação, perdi a pasta pessoal que existia na partição “Home5” — e tive de copiar outra, de outra distro (MX Linux), para poupar trabalho.

Na segunda instalação, lembrei daquele desastre, e tratei de voltar atrás, para impedir isso:

Resumo da instalação do PCLinuxOS — agora, sem a “Home5”

Apenas a partição “Linux5” deveria ser formatada — uma exigência de quase todos os instaladores, para assegurar que a partição-raiz do sistema esteja “limpa”, sem restos de qualquer instalação anterior.

A partição EFI não seria formatada. — Os instaladores costumam evitar esse desastre — pois é comum haver ali bootloaders de outros sistemas operacionais.

Também me certifiquei de que a partição Swap não seria formatada — pois isso iria alterar seu identificador UUID — o que me obrigaria a editar os arquivos /etc/fstab de todas as minhas outras distros, instaladas em dualboot / multiboot.

Na primeira de minhas 4 instalações, não entendi como evitar que a partição /home (Home5) fosse formatada. — Perdi as configurações que estavam nela.

Na instalação seguinte (mesma partição), a única solução que encontrei, foi não incluir a partição “Home5” na instalação. — É fácil incluí-la no /etc/fstab, mais tarde.

Em outras tentativas (3ª e 4ª), descobri como evitar esse problema:

O instalador automaticamente “decide” formatar a partição /home

Cliquei com o botão direito do mouse na linha da partição /home e escolhi “Editar”. — No diálogo que se segue, abri o menu suspenso de seleção do campo “Formatar como” — e cliquei na linha (em branco!), acima da primeira opção. — Não existe nada escrito, mas é ali que está a opção de “não formatar”:

Desmarcando “formatar” a partição /home

Desse modo, consegui evitar que a partição /home fosse formatada — e pude escolher a partição EFI:

Partição /home marcada para não formatar — e escolha da partição EFI

Em resumo, minhas dificuldades nasceram de 2 detalhes:

1) O cabeçalho da coluna “Formatar” desaparece quando se rola para baixo uma longa lista de partições. — Isto só foi um problema, porque me acostumei com outros instaladores, onde a coluna de “formatos” é apenas uma indicação do sistema de arquivos; enquanto a marca de “Formatar” aparece em outra coluna. — Mas acredito que a maioria dos usuários não tenha uma lista tão longa de partições, então isso deve afetar poucas pessoas:

Seleção completa das partições para a instalação do PCLinuxOS

2) A opção ”Não formatar” está em branco, na lista suspensa de formatos a escolher — e só encontrei por “intuição”. — No entanto, vi apenas um usuário embaraçado com isso, no Fórum do PCLinuxOS.

Flatpak

Preparação do Easy Flatpak Installer ao abrir pela primeira vez

Esta foi a primeira vez que instalei Flatpak — pois até agora eu vinha evitando pacotes Flatpak, Snap, AppImage etc., em todas as distros.

No Arch, uso o mínimo possível de pacotes do AUR. — No openSUSE, o mínimo possível de pacotes do Pakman Essentials. — No Fedora, o mínimo possível de pacotes do RPM Fusion. — Não uso pacotes PPA em distros de base Ubuntu.

O primeiro Flatpak que instalei foi o KRuler, para medir a escala visual da sessão Live — pois a imagem ISO era de Set. 2025 (KDE Apps 25.08.5), e já estávamos em Jan. 2026 (KDE Apps 25.12.0). — Instalar o KRuler “oficial” exigiria atualizar todo o KDE Plasma, Apps, Qt, Framework.

Ao abrir o Easy Flatpak, ele baixou um arquivo que ainda não entendo, e tornou a fechar. — Foi preciso abri-lo outra vez — e só então, ele carregou as informações atualizadas do repositório (Flathub).

Instalação do KRuler pelo Easy Flatpak, no Live PCLinuxOS

Na primeira tentativa de instalação, deixei desativado o botão deslizante “Escopo Usuário” — e depois de baixar, instalar etc., ele avisou que não foi possível, porque o usuário não tinha permissão. — Fiz de novo, com “Escopo Usuário”, e funcionou.

Download e instalação do Google-Earth em Flatpak, no PCLinuxOS

Tempos depois, com o PCLinuxOS já instalado no computador, decidi instalar 2 pacotes Flatpak que não existem nos repositórios oficiais da distro: — O Google-Earth e o Foliate.

Experimentei um caminho diferente: — Entrei no Flathub, baixei o pacote — e executei o comando indicado para fazer sua instalação:

$ cd Downloads

$ ls
com.google.EarthPro.flatpakref

$ date; flatpak install com.google.EarthPro.flatpakref; date
Mon Dec 22 01:15:33 PM -03 2025
Required runtime for com.google.EarthPro/x86_64/stable (runtime/org.freedesktop.Platform/x86_64/24.08) found in remote flathub-1
Do you want to install it? [Y/n]:

com.google.EarthPro permissions:
    ipc      network      pulseaudio      x11      dri      file access [1]     dbus access [2]

    [1] xdg-download
    [2] org.freedesktop.Notifications

        ID                                              Branch                Op           Remote              Download
 1. [✓] org.freedesktop.Platform.GL.default             24.08                 i            flathub-1           144.7 MB / 145.4 MB
 2. [✓] org.freedesktop.Platform.GL.default             24.08extra            i            flathub-1            24.0 MB / 145.4 MB
 3. [✓] org.freedesktop.Platform.Locale                 24.08                 i            flathub-1            42.8 MB / 388.2 MB
 4. [✓] org.freedesktop.Platform.VAAPI.Intel            24.08                 i            flathub-1            14.8 MB / 15.0 MB
 5. [✓] org.freedesktop.Platform.openh264               2.5.1                 i            flathub-1           913.7 kB / 971.4 kB
 6. [✓] org.freedesktop.Platform                        24.08                 i            flathub-1           192.9 MB / 269.3 MB
 7. [✓] com.google.EarthPro                             stable                i            flathub-1            60.9 MB / 61.0 MB

Installation complete.
Mon Dec 22 01:16:37 PM -03 2025

Aplicativos Flatpak têm acesso limitado dentro do PC, e o Google-Earth não pôde abrir o arquivo “myplaces.kml” na pasta /home de outra distro. — Copiei para a pasta Downloads do PCLinuxOS, e assim pude importar as camadas atualizadas:

Camadas importadas do “myplaces.kml” de outra distro

Por fim, usei o mesmo comando — sem baixar o pacote — após seguir uma dica do PCLinuxOS Magazine:

PCLinuxOS Magazine - 2023-07 (vol. 198)

1) Install Flatpak utility via Synaptic

2) As root:

# flatpak remote-add --if-not-exists flathub https://flathub.org/repo/flathub/flatpakrepo

3) Restart PC

$ flatpak search earth
Name            Description                                             Application ID                   Version      Branch Remotes
Google Earth P… 3D planet viewer                                        com.google.EarthPro              7.3.6        stable flathub
(...)

$ flatpak install flathub com.google.EarthPro
Looking for matches…
Remote ‘flathub’ found in multiple installations:

   1) system
   2) user

Which do you want to use (0 to abort)? [0-2]: 1
Required runtime for com.google.EarthPro/x86_64/stable (runtime/org.freedesktop.Platform/x86_64/25.08) found in remote flathub
Do you want to install it? [Y/n]: y

com.google.EarthPro permissions:
    ipc      network     pulseaudio     x11     dri     file access [1]     dbus access [2]

    [1] xdg-download
    [2] org.freedesktop.Notifications

        ID                                                Branch                 Op            Remote             Download
 1. [✓] org.freedesktop.Platform.GL.default               25.08                  i             flathub            140.4 MB / 141.4 MB
 2. [✓] org.freedesktop.Platform.GL.default               25.08-extra            i             flathub             25.2 MB / 141.4 MB
 3. [✓] org.freedesktop.Platform.Locale                   25.08                  i             flathub            180.5 MB / 378.7 MB
 4. [✓] org.freedesktop.Platform.VAAPI.Intel              25.08                  i             flathub             13.6 MB / 13.7 MB
 5. [✓] org.freedesktop.Platform.codecs-extra             25.08-extra            i             flathub             14.2 MB / 14.4 MB
 6. [✓] org.gtk.Gtk3theme.Adwaita-dark                    3.22                   i             flathub              4.7 kB / 1.5 kB
 7. [✓] org.freedesktop.Platform                          25.08                  i             flathub            200.6 MB / 253.4 MB
 8. [✓] com.google.EarthPro                               stable                 i             flathub             61.8 MB / 62.0 MB

Installation complete.


$ flatpak remotes                ### Lists all configured remote repositories
Name    Options
flathub system
flathub user

Dessa vez, o instalador CLI do pacote Flatpak remoto perguntou se eu queria instalar “system” ou “user”:

Instalação de pacote Flatpak remoto por comando

xxxx

Mountpoints

Houve uma época em que eu preferia pontos de montagem mais curtos — e gostei quando vi que o PCLinuxOS usava “/media/LABEL”. — Hoje, prefiro o tradicional “/run/media/USER/LABEL” das distros não-Debian — ou mesmo o “media/USER/LABEL” das distros Debian.

Para isso, criei o arquivo “/etc/udev/rules.d/99-udisks2.rules”, com este conteúdo:

   # UDISKS_FILESYSTEM_SHARED
   # ==1: mount filesystem to a shared directory (/media/VolumeName)
   # ==0: mount filesystem to a private directory (/run/media/$USER/VolumeName)
   # See udisks(8)
   ENV{ID_FS_USAGE}=="filesystem|other|crypto", ENV{UDISKS_FILESYSTEM_SHARED}="0"

xxxx

___________________
• Publicado em 25 Dezembro 2025; e desenvolvido até Fevereiro 2026.

— … ≠ • ≠ … —

Mandrake / Mandriva

PC desktop UEFI / GPT

Linux Mint (KDE), Kubuntu LTS, KDE Neon, revisitados

noreply@blogger.com (Mboaba) — Fri, 01 Aug 2025 15:29:00 +0000

Kubuntu 24.04.2 LTS

Voltei a instalar meus velhos conhecidos Kubuntu LTS e Linux Mint (com KDE), para ver como estão atualmente — mas também para ter mais algumas distros “estáveis”, com o velho e bom KDE Plasma 5, no meu PC multiboot.

Kubuntu LTS foi minha distro principal durante anos, desde 2009 — mas perdi contato com ele, em meados de 2019. — Eu ainda não o tinha instalado no meu PC atual, desde 2020.

Linux Mint 22.1 (Xia) com KDE Plasma

Linux Mint foi minha “segunda distro principal” por longos períodos, também desde 2009 — e em 2016 cheguei a considerá-lo minha distro principal, em sua versão KDE. — Voltei a instalá-lo no meu PC atual (com KDE), em 2020, por pouco mais de um ano.

KDE Neon (noble)

Uma semana depois, resolvi instalar também o KDE Neon. — Um trio completo, para lembrar meus primeiros tempos no Linux (2007-2016).

Comecei a usar o KDE Neon em 2016, ainda recém-lançado — e passei a considerá-lo minha distro principal já no ano seguinte — mas com o tempo acabei preferindo outras, 100% “rolling release”.

Continuei usando o KDE Neon no meu PC atual, a partir de 2020 — mas demorei a fazer upgrade para o Plasma 6, e quando tentei, talvez fosse tarde demais. Não deu certo. — Acabei deletando no final de 2024.

Índice

Base comum “Ubuntu LTS”

Repositórios e pacotes, na prática

Hardware e Partições
Download, Boot, Live
Instalando

Instalação do Kubuntu
Instalação do Linux Mint
Instalação do KDE Neon

Configurando

Configuração do Kubuntu
Configuração do Linux Mint
Configuração do KDE Neon

Extraindo Log's legíveis
Atualização do “linux-firmware”
Upgrade do Mint 22.1 “Xia” para 22.3 “Zena”
Mudando a /home para XFS
Final, finais

Base comum “Ubuntu LTS”

Organização das fontes de software do KDE Neon, do Kubuntu e do Linux Mint

O que há em comum entre essas 3 distros é que usam a mesma base estável Ubuntu LTS “Noble Numbat” (+updates, security):

----------------------
Kubuntu LTS - sources:
----------------------
# cat /etc/apt/* | grep 'http\|ftp'

deb http://archive.ubuntu.com/ubuntu/ noble main restricted universe multiverse
deb http://archive.ubuntu.com/ubuntu/ noble-updates main restricted universe multiverse

# cat /etc/apt/sources.list.d/* | grep -A 2 'http\|ftp'

deb [arch=amd64] https://dl.google.com/linux/chrome/deb/ stable main
--
URIs: http://archive.ubuntu.com/ubuntu
Suites: noble noble-updates noble-backports
Components: main universe restricted multiverse
--
URIs: http://security.ubuntu.com/ubuntu/
Suites: noble-security
Components: main universe restricted multiverse

Optei pela instalação mínima do Kubuntu. — Com isso, evitei que fosse instalada a infraestrutura Snapd (e seu Firefox).

Eu acrescentei o repositório do Google Chrome, às 3 distros.

-------------------
KDE Neon - sources:
-------------------
# cat /etc/apt/* | grep 'http\|ftp'

deb http://archive.ubuntu.com/ubuntu/ noble main restricted universe multiverse
deb http://security.ubuntu.com/ubuntu/ noble-security main restricted universe multiverse
deb http://archive.ubuntu.com/ubuntu/ noble-updates main restricted universe multiverse

# cat /etc/apt/sources.list.d/* | grep 'http\|ftp'

deb [arch=amd64] https://dl.google.com/linux/chrome/deb/ stable main
URIs: http://archive.neon.kde.org/user
URIs: https://packages.mozilla.org/apt

KDE Neon acrescenta um repositório “Neon”, abrigado na Fundação KDE e.V., com o Plasma mais recente — e um repositório Mozilla, para o Firefox. — Não vejo “backports”.

---------------------
Linux Mint - sources:
---------------------
# cat /etc/apt/* | grep 'http\|ftp'

# cat /etc/apt/sources.list.d/* | grep -A 2 'http\|ftp'

deb [arch=amd64] https://dl.google.com/linux/chrome/deb/ stable main
deb https://mint-packages.c3sl.ufpr.br xia main upstream import backport

deb http://ubuntu.c3sl.ufpr.br/ubuntu noble main restricted universe multiverse
deb http://ubuntu.c3sl.ufpr.br/ubuntu noble-updates main restricted universe multiverse
deb http://ubuntu.c3sl.ufpr.br/ubuntu noble-backports main restricted universe multiverse
deb http://security.ubuntu.com/ubuntu/ noble-security main restricted universe multiverse

Linux Mint acrescenta um repositório com seus próprios pacotes — e que inclui seu próprio Firefox.

Cada uma dessas distros organiza e “escreve” a configuração das fontes de software de um modo diferente — no velho formato, no arquivo “sources.list” — e / ou em vários arquivos com o novo formato, na pasta “sources.list.d” — o que é meio confuso (incluindo o que parecem ser algumas repetições).

Essas diferenças também refletem políticas divergentes de como lidar com pacotes de outras fontes e formatos, como PPAs, Snap, Flatpak etc. — além do uso preferencial de algum gerenciador de pacotes específico, como o “pkcon” (PackageKit), no caso do KDE Neon; — ou o Update Manager, no caso do Linux Mint.

As prioridades de cada repositório e outras configurações são definidas por arquivos nas pastas “preferences.d” e “apt.conf.d” — e outros pequenos detalhes. — Deixo isso para quando eu puder dedicar todo tempo e atenção ao assunto.

Repositórios e pacotes, na prática

Neste momento, vou apenas examinar algumas diferenças entre o Kubuntu, o Linux Mint, o KDE Neon, quando o apt tenta instalar os navegadores Chromium e Firefox: — Qual pacote “.deb” é baixado? De onde vem? Quem empacotou? — E como (e por que) ele é trocado por um pacote “.snap2”, no caso do Kubuntu?

Para maior clareza, comparei também o comportamento observado no Debian (base original do Ubuntu) — e no MX Linux (um Debian modificado).

No Debian, o comando apt encontra pacotes “.deb” de 70 a 80 MB — empacotados por mantenedores do próprio Debian e disponibilizados em seu repositório principal (Main) — e que depois de instalados ocupam pouco menos de 300 MB:

-------------------------
--------- Debian --------
-------------------------

$ apt show chromium | grep 'Maintainer\|Size\|Sources'

Maintainer: Debian Chromium Team [chromium@packages.debian.org]
Installed-Size: 286 MB
Download-Size: 80.1 MB
APT-Sources: http://ftp.br.debian.org/debian testing/main amd64 Packages

$ apt show firefox-esr | grep 'Maintainer\|Size\|Sources'

Maintainer: Maintainers of Mozilla-related packages [team+pkg-mozilla@tracker.debian.org]
Installed-Size: 272 MB
Download-Size: 71.0 MB
APT-Sources: http://ftp.br.debian.org/debian testing/main amd64 Packages

No Kubuntu, o comando apt encontra pacotes “.deb” ridiculamente pequenos, de 50 a 80 kB — empacotados por mantenedores ligados à Canonical (Ubuntu), e oferecidos no repositório “Universe” (Chromium); ou no “Main” (Firefox) — e que depois de instalados, supostamente ocupariam ridículos 100 a 125 kB.

Na verdade, são pacotes “dummy” — vazios, pois não contêm binários executáveis, nem bibliotecas etc. — Eles descrevem a si mesmos como “transicionais”. Servem de “transição” para outra coisa.

Sua única função é “depender” de outros pacotes, provocando assim a instalação dessas dependências — os pacotes “chromium.snap”, “firefox.snap” — e, naturalmente, a infraestrutura para lidar com eles, formada pelo pacote “snapd” e suas dependências, caso ainda não estejam instalados:

-------------------------
-------- Kubuntu --------
-------------------------

$ apt show chromium-browser | grep 'Maintainer\|Size\|Sources\|snap'

Version: 2:1snap1-0ubuntu2
Maintainer: Ubuntu Developers [ubuntu-devel-discuss@lists.ubuntu.com]
Installed-Size: 105 kB
Pre-Depends: debconf, snapd
Download-Size: 50,0 kB
APT-Sources: http://ubuntu.c3sl.ufpr.br/ubuntu noble/universe amd64 Packages
Description: Transitional package - chromium-browser -> chromium snap
 chromium-browser is now replaced by the chromium snap.

$ apt show firefox  | grep 'Maintainer\|Size\|Sources\|snap'

Version: 1:1snap1-0ubuntu5
Maintainer: Ubuntu Mozilla Team [ubuntu-mozillateam@lists.ubuntu.com]
Installed-Size: 124 kB
Pre-Depends: debconf, snapd (>= 2.54)
Breaks: firefox-dbg (<< 1:1snap1), firefox-dev (<< 1:1snap1), firefox-geckodriver (<< 1:1snap1), firefox-mozsymbols (<< 1:1snap1)
Replaces: firefox-dbg (<< 1:1snap1), firefox-dev (<< 1:1snap1), firefox-geckodriver (<< 1:1snap1), firefox-mozsymbols (<< 1:1snap1)
Download-Size: 77,3 kB
APT-Sources: http://ubuntu.c3sl.ufpr.br/ubuntu noble/main amd64 Packages
Description: Transitional package - firefox -> firefox snap
 firefox is now replaced by the firefox snap.

No Linux Mint, o apt encontra pacotes “.deb” de 80 a 115 MB — empacotados pela equipe dessa distro, e disponibilizados no repositório “Upstream” — e que depois de instalados ocupam 300 a 370 MB:

-------------------------
---------- Mint ---------
-------------------------

$ apt show chromium | grep 'Maintainer\|Size\|Sources\|snap'

Maintainer: Clement Lefebvre [root@linuxmint.com]
Installed-Size: 366 MB
Download-Size: 113 MB
APT-Sources: https://mint-packages.c3sl.ufpr.br xia/upstream amd64 Packages

$ apt show firefox | grep 'Maintainer\|Size\|Sources\|snap'

Maintainer: Clement Lefebvre [root@linuxmint.com]
Installed-Size: 296 MB
Download-Size: 87,4 MB
APT-Sources: https://mint-packages.c3sl.ufpr.br xia/upstream amd64 Packages

No KDE Neon, o apt encontra o pacote “.deb” do Firefox no repositório principal (Main) do Mozilla — mas o pacote Chromium que encontra é o mesmo “dummy” fornecido pela Canonical:

-------------------------
-------- KDE Neon -------
-------------------------

$ apt show chromium-browser | grep 'Maintainer\|Size\|Sources\|snap'

Version: 2:1snap1-0ubuntu2
Maintainer: Ubuntu Developers [ubuntu-devel-discuss@lists.ubuntu.com]
Installed-Size: 105 kB
Pre-Depends: debconf, snapd
Download-Size: 50.0 kB
APT-Sources: http://archive.ubuntu.com/ubuntu noble/universe amd64 Packages
Description: Transitional package - chromium-browser -> chromium snap

$ apt show firefox | grep 'Maintainer\|Size\|Sources\|snap'

Maintainer: Mozilla [release@mozilla.com]
Installed-Size: 299 MB
Download-Size: 82.3 MB
APT-Sources: https://packages.mozilla.org/apt mozilla/main amd64 Packages

O MX Linux (um Debian stable modificado) também parece ter-se dedicado apenas ao Firefox: — Seu apt encontra o pacote “firefox.deb” no seu repositório principal (Main) — mas o Chromium vem do repositório “secutiry” do Debian:

-------------------------
-------- MX Linux -------
-------------------------

$ apt show chromium | grep 'Maintainer\|Size\|Sources\|snap'

Maintainer: Debian Chromium Team [chromium@packages.debian.org]
Installed-Size: 254 MB
Download-Size: 70.7 MB
APT-Sources: http://security.debian.org/debian-security bookworm-security/main amd64 Packages

$ apt show firefox | grep 'Maintainer\|Size\|Sources\|snap'

Maintainer: Mike Purtell [mmikeinsantarosa@mxlinux.org]
Installed-Size: 296 MB
Download-Size: 82.1 MB
APT-Sources: https://mxlinux.c3sl.ufpr.br/mx-workspace/mx/repo bookworm/main amd64 Packages

Hardware e Partições

Partições utilizadas: Linux5, Linux8, Linux10 (antes e depois)

Meu hardware ainda é o mesmo PC desktop de 2020 — agora com um 2º SSD — sem placa GPU, pois não instalo jogos, nem faço edição pesada de videos, compilações, não caço bitcoins, nem uso IA:

      MoBo: TUF B360M-PLUS GAMING/BR, BIOS 2401 03/22/2019 - ASUSTeK
      iGPU: Intel Corporation UHD Graphics 630 (Desktop)
       CPU: 6 × Intel® Core™ i5-9400 CPU @ 2.90GHz ( 800 ~ 4100 MHz )
    Memory: 15.5 GiB of RAM

  /dev/sda   SSD  Sata3  Kingston         SA400S37480G         447.13 GiB
  /dev/sdb   SSD  Sata3  Western Digital  WD Green 2.5 480GB   447.13 GiB
  /dev/sr0   DRW  Sata3  ASUS             DRW-24F1MT

O 1º SSD tem partições para 6 distros em dualboot (Linux1 a Linux6; e Home1 a Home6) — e o 2º SSD, também (Linux7 a Linux12; Home7 a Home12) — além de uma partição EFI em cada um (EFI, EFI2):

$ date; lsblk -o name,mountpoint,label,fstype,size
Fri  1 Aug 05:13:23 -03 2025

NAME    MOUNTPOINT                  LABEL     FSTYPE   SIZE
sda                                                  447.1G
├─sda1  /boot/efi                   EFI       vfat       2G
├─sda2  /run/media/flavio/Linux1    Linux1    btrfs     50G
├─sda3  /                           Linux2    ext4      30G
├─sda4  /run/media/flavio/Linux3    Linux3    ext4      30G
├─sda5  /run/media/flavio/Linux4    Linux4    ext4      30G
├─sda6  /run/media/flavio/Linux5    Linux5    ext4      30G
├─sda7  /run/media/flavio/Linux6    Linux6    ext4      30G
├─sda8  /run/media/flavio/Home1     Home1     xfs       15G
├─sda9  /home                       Home2     xfs       15G
├─sda10 /run/media/flavio/Home3     Home3     ext4      15G
├─sda11 /run/media/flavio/Home4     Home4     ext4      15G
├─sda12 /run/media/flavio/Home5     Home5     xfs       15G
├─sda13 [SWAP]                                swap      11G
├─sda14 /run/media/flavio/Home6     Home6     ext4      15G
└─sda15 /run/media/flavio/Warehouse Warehouse ext4   144.1G
sdb                                                  447.1G
├─sdb1  /run/media/flavio/Linux7    Linux7    ext4      30G
├─sdb2  /run/media/flavio/Linux8    Linux8    ext4      30G
├─sdb3  /run/media/flavio/Linux9    Linux9    ext4      30G
├─sdb4  /run/media/flavio/Linux10   Linux10   ext4      30G
├─sdb5  /run/media/flavio/Linux11   Linux11   ext4      60G
├─sdb6  /run/media/flavio/Linux12   Linux12   ext4      30G
├─sdb7  /run/media/flavio/Home7     Home7     ext4      15G
├─sdb8  /run/media/flavio/Home8     Home8     ext4      15G
├─sdb9  /run/media/flavio/Home9     Home9     ext4      15G
├─sdb10 /run/media/flavio/Home10    Home10    ext4      15G
├─sdb11 /run/media/flavio/Home11    Home11    ext4      15G
├─sdb12 /run/media/flavio/Home12    Home12    ext4      15G
├─sdb13 /run/media/flavio/Midia     Midia     ext4   142.6G
├─sdb14 /run/media/flavio/Sites     Sites     ext4       2G
├─sdb15 /run/media/flavio/Works     Works     ext4       2G
└─sdb16                             EFI2      vfat     511M
sr0                                                   1024M

(Eu já usava XFS na partição “Home1”, do openSUSE: — Nenhum problema em 8 anos, desde Janeiro 2017. — Experimentei, agora, converter para XFS a partição “Home5”, do KDE Neon — e em seguida, também a partição “Home2”, do Arch Linux).

Tenho apenas 1 partição Swap, de 11 GiB, comum a todas as distros — pois não uso “Hibernar” (só “Sleep”). — Em mais de 5 anos, só vi a partição Swap ser utilizada em 2 ou 3 momentos, pois evito manter mais de 3 ou 4 abas abertas no Chrome; e não realizo atividades intensivas.

Os documentos são salvos em 2 partições de 140+ GiB, comuns a todas as distros — “Warehouse”, “Midia” — de modo que as partições /home, de 15 GiB (cada), guardam só as pastas pessoais de usuário, com as suas configurações.

Tudo isso, são opções “pessoais” (minhas). — Ninguém “tem de” fazer como eu. — Mas este registro só pode ser útil, se incluir todas as variáveis, de modo transparente.

“/home” partitions:

  Old times                       Before                Now

  01 - openSUSE                     01 - openSUSE    01 - openSUSE
  02 - Arch                         02 - Arch        02 - Arch
  03 - Debian                       03 - Debian      03 - Debian
  04 - Fedora                       04 - Fedora      04 - Fedora
  05 - KDE Neon  (Plasma 5, X11)                     05 - KDE Neon    (Plasma 6, X11)
  06 - PCLinuxOS                    06 - PCLinuxOS   06 - PCLinuxOS
  07 - Mageia                       07 - Mageia      07 - Mageia
  08 - Fedora    (Plasma 6, X11)                     08 - Kubuntu LTS (Plasma 5, X11)
  09 - Void                         09 - Void        09 - Void
  10 - Manjaro   (Plasma 6, X11)                     10 - Linux Mint  (Plasma 5, X11)
  11 - Redcore
  12 - MX Linux                     12 - MX Linux    12 - MX Linux

Old times:

Linux5  - KDE Neon        2024-12-01  deleted Linux5,     preserved Home5
Linux8  - Slackware       2024-12-01  deleted Linux8,     preserved Home8
Linux8  - Fedora          2025-06-01  deleted Linux8,     preserved Home8
Linux10 - Manjaro         2024-12-01  deleted Linux10-11, preserved Home10-11
Linux11 - Redcore         2024-12-01  deleted Linux10-11, preserved Home10-11

A partição Home5 guardava configurações Plasma 5 (X11) de um antigo KDE Neon. — A partição Home8 guardava configurações Plasma 6 (X11) de uma experiência com Fedora 42. — A partição Home10 guardava configurações Plasma 6 (X11), de um antigo Manjaro.

Houve, portanto, uma inversão — em que 2 distros com Plasma 5 “herdaram” partições /home configuradas em Plasma 6 — e vice-versa.

Depois de instalados, apenas o Kubuntu iniciou sem o Painel, e portanto sem Menu — mas foi fácil corrigir isso. — O KDE Neon e o Linux Mint iniciaram normalmente.

Download, Boot, Live

Faltava um “mmx64.efi” na ISO do Live Mint

Minha intenção era instalar o Linux Mint 22.1 Xfce, ambiente desktop (DE) mais fácil de remover, após instalar o KDE Plasma. — Conferi a integridade pelo sha256sum, “queimei” no Pendrive pelo comando dd, mas não consegui dar boot — por falta de um arquivo “mmx64.efi” em seu \EFI\BOOT, segundo a mensagem de erro.

De fato, ali havia “bootx64.efi” e “grubx64.efi”. — Mais tarde, vi dizerem que “basta” copiar “grubx64.efi” para o PC, renomear como “mmx64.efi”, e copiar de volta para o Pendrive — mas não é tão simples, pois o Pendrive é read-only... e aí, começa outra saga de pesquisar, ler, tentar etc.

Escolhi outra solução, bem mais simples e imediata — que é dar boot por um Live Ubuntu — e depois disso, o Live Mint consegue dar boot.

Tela do MOK no boot do Live Kubuntu

Baixei o Kubuntu, “queimei” pelo K3b em DVD, inicializei — e aproveitei para instalar. — Horas depois, voltei ao Pendrive do Live Mint, ele finalmente conseguiu dar boot, e também instalei.

Live Mint finalmente chegou ao Grub, após um boot do Live Kubuntu

Fiquei então com 2 distros para me divertir.

Uma semana depois, resolvi baixar e instalar também o KDE Neon.

Eu não tinha mais interesse no KDE Neon — “meio” abandonado, como ficou evidente na passagem para o KDE Plasma 6 — mas a sensação de que possa ser descontinuado me despertou o interesse em documentá-lo mais um pouco, “antes que acabe”.

22 Set. 2025 - Precisei de uma partição para fazer nova instalação do PCLinuxOS, e optei por deletar o KDE Neon.

Instalação do Kubuntu

Resumo da instalação do Kubuntu

No Grub do Live Kubuntu selecionei a opção “Try or Install”. — Na tela inicial selecionei idioma British English (UK), e escolhi “Instalar”, sem carregar uma sessão Live Desktop (Try). — Na Localização, escolhi horário de São Paulo (BRT). — No Teclado, aceitei “Generic 105 Keys” (pode ser mudado depois), e escolhi Português do Brasil, modelo “Default”, que costuma significar ABNT2 (fiz o teste, para ter certeza).

Instalação mínima do Kubuntu

Em Personalização, alterei o Modo de Instalação, de “Normal” — que incluiria Navegador, Utilitários, Office, Jogos e Players de Mídia — para “Instalação Mínima”, que inclui apenas o ambiente (DE).

Sob o nome genérico “navegador”, está o Firefox — em Snap — o que implicaria na instalação da infraestrutura Snapd.

Também dispensei “Pacotes de Terceiros”, que incluem Element, Virtual Machine Manager, Krita. — E deixei desmarcada a opção de baixar e instalar atualizações “following installation”, que nunca funcionou para mim no passado. — Atualizar manualmente é simples, fácil, rápido, e proporciona uma boa noção de quanta coisa mudou desde o lançamento da ISO Kubuntu 24.04.2.

Na etapa de Particionamento, selecionei Particionamento Manual, pois eu já tinha as partições Linux8, Home8, EFI2 prontas. Bastava selecionar o 2º SSD (sdb), escolher as partições e Editar as opções de cada uma. — Para Linux8, selecionei Formatar, sem alterar o tamanho, nem o sistema de arquivos ext4; e ponto de montagem “/”. Preenchi o campo do rótulo (Label) com “Linux8”, mas não foi aplicado. — Para Home8, selecionei “Manter”; e ponto de montagem “/home”. — Para EFI2, “Manter”, ponto de montagem “/boot/efi”, e sinalizador “boot”.

Arquivos fstab do Kubuntu e do Linux Mint

Esqueci de configurar a partição Swap — e o instalador do Kubuntu criou um arquivo-swap (swapfile) de 512 MiB. — Acima: - Fiz uma cópia do fstab do Mint, editada para facilitar a comparação. Os originais ainda são de 13 Jul. 2025, às 21:06 e 22:05, respectivamente.

Em Usuários, preenchi Nome (completo), ID de Login, nome da máquina “Linux8”, senha do usuário, e habilitei Login Automático — em sessão X11, que ainda é o meu padrão, por enquanto. — Só estou testando Wayland no Fedora.

O apelido “ID de Login” será também o nome da pasta pessoal do usuário. — Escolho sempre o mesmo — pois desse modo aproveito a pasta já existente, com as configurações pessoais acumuladas nas distros anteriores.

Instalação do Linux Mint

Teclado, Codecs e Particionamento manual, no Instalador do Linux Mint (ilustrativo)

Iniciei uma sessão Live Mint Xfce, e abri logo o Instalador.

Deixei o idioma Inglês (não vi sub-opções). — Mudei o Teclado para “Português (Brasil)”. — Marquei para instalar Codecs de mídia. — Escolhi o particionamento manual, chamado “Something else”.

Particionamento manual no Instalador do Linux Mint (ilustrativo)

Abriu-se a janela “Tipo de instalação”, exibindo uma longa lista, começando pelo 1º SSD (sda), suas partições; e depois o 2ª SSD (sdb), e suas partições.

O dispositivo de Bootloader veio pré-selecionado “/dev/sda”. — Selecionei a partição EFI2 (sdb16).

Ao escolher uma partição e clicar em “Mudar” para configurá-la, o campo “Usar como” aparece com “Não usar”. — Ao selecionar “ext4”, aparece mais um campo: — Ponto de montagem.

Selecionei a partição Linux10, marquei para Formatar, escolhi sistema de arquivos “ext4”, ponto de montagem “/”.

A “navegação” foi meio “às cegas”, pois essa janela “Tipo de Instalação” não mostra os rótulos (Label) das partições — que criei exatamente para facilitar minha vida.

Escolhi a partição que devia ser Home10, contando nos dedos das mãos. — Selecionei o ponto de montagem “/home”, não formatar, e Ok.

Ao terminar as configurações e clicar em “Instalar agora”, o instalador exibiu a tela de Fuso horário, e escolhi São Paulo (BRT). — O instalador avançou para a última etapa: — Nome do usuário, Nome do computador, ID de Login, senha. — Habilitei o Login Automático.

As imagens do Instalador do Mint (acima) foram feitas muito tempo depois, e são meramente ilustrativas do processo — não do momento da instalação.

Instalação do KDE Neon

Configurações regionais no instalador Calamares do KDE Neon

Abri o instalador Calamares em sessão Live do KDE Neon — mudei o Idioma, de Inglês dos EUA para Inglês Britânico (UK) — selecionei o Fuso horário BRT (São Paulo) — e mudei os formatos de números e datas, de Português (Brasil) para Inglês Britânico (UK). — Escolhi Teclado “Português (Brasil) - Default”.

Optei pelo Particionamento manual, selecionei a partição Linux5 para “/” e Home5 para “/home”. — Acabei não configurando a partição EFI, recebi o aviso — mas pude prosseguir mesmo assim.

Os bootloaders do Kubuntu, do Mint e do KDE Neon (nas partições EFI) tendem a se embaralhar — inclusive, usando o mesmo nome “Ubuntu”, o que dificulta saber quem é quem. — Às vezes, o bootloader de um leva ao Grub de outro. Procuro nunca usá-los (exceto para teste e documentação).

Também acabei não configurando a partição Swap — mas o instalador não criou arquivo Swap.

Preenchi Nome, ID, senha do usuário — Nome da máquina “Linux5” — e habilitei o Login Automático.

Configuração do Kubuntu

Kubuntu sem Painel. Atualizei pelo console virtual (tty)

O Kubuntu instalado carregou sem Painel, e portanto sem Menu. — Minha primeira providência foi alternar para o console virtual tty3 e fazer uma atualização completa. — Não resolveu o problema mas, de qualquer jeito, eu teria de atualizar tudo, antes de instalar novos pacotes.

Adicionando e configurando Painel no Kubuntu

Pelo menu de contexto (right-click), adicionei um Painel. — Não era o que eu tinha nessa partição “Home8”, quando ela pertencia ao Fedora ou ao Slackware, então tive de configurá-lo, “do zero”: — Ícone do Menu, Lançadores Rápidos (Quick Launch), Icons-only Taskmanager etc., além de trocar o Menu padrão.

A maior parte das demais configurações foi preservada na “Home8”, faltando só pequenos ajustes aqui e ali. — Não tenho pressa (pois tenho outras distros em dualboot / multiboot, prontas para usar): — Posso ajustar cada coisa, quando tiver um tempo.

Instalei o Synaptic, seu “apt-xapian-index” (filtro rápido), o Conky, lm-sensors, binutils, html2text, htop, Neofetch, inxi, Midnight Commander (mc), KWrite, Gimp, KRuler, gnome-screenshot. — A lista é grande, e não tenho pressa de instalar tudo de uma vez.

Configurações do Plasma Discover, sem Snap nem Flatpak

Removi “unattended-upgrades”, e tentei desativar a verificação e notificação automática de atualizações pelo Plasma Discover, mas elas ainda prosseguem. — Em geral, removo PackageKit e Plasma Discover, para liquidar o assunto de vez — mas nessa instalação ainda não fiz isso, para poder observá-los um pouco mais.

Snap encabeça as configurações do Discover, com o botão “Tornar padrão” — que na verdade ainda teria de instalar o “Snapd” — o que eu evitei, ao escolher a “Instalação Mínima” do Kubuntu.

Por via das dúvidas, me certifiquei de que não tenho nenhum pacote Snap ou Flatpak instalado. — Na verdade, nem suas bases:

2025-07-16 20:00:06

$ snap list
Command 'snap' not found, but can be installed with:
sudo apt install snapd

$ flatpak list
Command 'flatpak' not found, but can be installed with:
sudo apt install flatpak

Configuração do Linux Mint

Escolha de “espelhos” (mirrors) no Mint — refeita após upgrade para 22.3 “Zena”

Evitei configurar qualquer coisa no ambiente Xfce, para não interferir nas configurações do KDE, que já existiam na partição “Home10”. — Sim, já vi as configurações de um ambiente desktop (DE) interferirem com as de outro DE, numa instalação com vários ambientes.

Achei mais prático instalar o KDE Plasma o mais rápido possível, em vez de investir tempo dentro do Xfce, que não uso há anos. — Por isso, não fiz capturas de tela (só fotos, aliás bem ruins), e agora exemplifico com imagens muito posteriores.

2025-07-16 - 20:41 - Instalei o Synaptic pelo comando upstream “sudo /usr/bin/apt install” — em vez do “apt do Linux Mint” — seja lá qual for a diferença entre um e outro:

$ sudo apt apdate

This is the Linux Mint "apt" command.

This commands acts as a wrapper for the APT package manager and many other useful tools such as apt-get, apt-cache, apt-mark, dpkg, aptitude...etc.

It is installed in /usr/local/bin/apt. To use the upstream apt command directly type /usr/bin/apt.

2025-07-16 - 20:58 - Abri o Update Manager (mintUpdate) e aceitei a sugestão de escolher “espelhos” (mirrors) locais. — Ele abre o Software Sources, que testa as velocidades, mas permite escolher os que você preferir — um, para os pacotes do Mint; e outro, para os do Ubuntu.

2026-01-16 - Tive de refazer a escolha de espelhos locais, depois do upgrade do Mint 22.1 “Xia” para 22.3 “Zena”. — A imagem (acima) ficou muito melhor — e ilustra com exatidão o procedimento de 6 meses antes.

Gerenciamento de software, drivers, kernels no Linux Mint

O gerenciamento de software do Mint é feito por vários pacotes próprios, representados por 4 nomes no Menu. — Eis um resumo incompleto:

Menu                Package             Description
----                -------             -----------
Software Manager    mintinstall         A software manager to easily install new applications.

Software Sources    mintsources         Configure the sources for installable software and updates.
                                           -- depends on mint-mirrors (...)
Update Manager      mintupdate          Helps installing security updates and new versions of packages.
                                           -- depends on mint-mirrors
                                           -- depends on mint-upgrade-info
                                           -- depends on apt, aptkit (...)

                    mint-mirrors        List of Linux Mint Repository mirrors.
                    mint-upgrade-info   Provides information to the Update Manager on how to perform distribution upgrades.
                    aptkit              transaction based package management service

Esses pacotes formam uma camada de conforto, que utiliza a infra-estrutura básica: — “dpkg” + “apt” — os únicos realmente necessários, pois são os que de fato gerenciam os pacotes da base “.deb”.

Essas camadas superpostas permitem que o usuário do Mint encontre toda facilidade e comodidade, apenas clicando em aplicativos GUI, sem recorrer a comandos complicados e abstrusos.

O “apt” é acionado de modo indireto, via AptKit — um “Serviço de gerenciamento de pacotes baseado em transações”, que foi criado (forked) em 2024 pelo Mint, a partir do AptDaemon. — A página no Github explica:

O AptKit permite executar tarefas de gerenciamento de pacotes em um processo em segundo plano controlado pelo DBus. É uma continuação do AptDaemon, que não recebe manutenção ativa e existe apenas no Ubuntu.

O AptDaemon foi fortemente inspirado pelo PackageKit, que, por política, não oferece suporte a recursos essenciais do apt.

Não me aprofundei no Driver Manager — sem interesse para mim. — Entre “mintdrivers”, “mint-drivers”, “driver-manager”, não consigo ter certeza de quais são “pacotes”, e quais são links simbólicos:

$ ls -o /usr/bin | grep driver
[...]
-rwxr-xr-x 1 root      105 2026-01-08 13:08 driver-manager
[...]
-rwxr-xr-x 1 root      352 2017-08-30 05:22 mint-drivers
lrwxrwxrwx 1 root       14 2026-01-08 13:08 mintdrivers     -> driver-manager

Existem outras camadas, vindas do Debian e / ou do Ubuntu — como o “unattended-upgrades” (só apareceu quando instalei o KDE), que instala atualizações de segurança em silêncio, sem perguntar e sem avisar — e o PackageKit, um serviço “universal”, que usa os gerenciadores de cada distro (apt, dnf, pacman etc.) para unificar os procedimentos. — Ambos podem ser desabilitados (só aprendi em 2026), mas há mais de 10 anos costumo removê-los.

Enfim, ao instalar o KDE Plasma, também recebi o Plasma Discover — “lojinha” que também costumo remover, há uns 10 anos.

Para todos os efeitos práticos, os aplicativos específicos do Linux Mint permitem ao usuário fazer todo o gerenciamento de software de maneira simples e descomplicada. — Eles já vêm configurados para dar a maior segurança ao usuário novato — mas permitem alterar esses parâmetros, com explicações claras a cada passo.

Tenho a impressão de que “unattended-upgrades” e PackageKit são desativados por padrão, no Mint — mas não verifiquei.

Pesquisa por pacotes no Histórico do Synaptic

Eu prefiro verificar manualmente as atualizações, uma vez por semana (em geral aos Domingos), pelo comando “apt update”, para “ver” se minha conexão e os “espelhos” estão ok — e em seguida aplicar as atualizações pelo Synaptic, que é uma interface (GUI) do “apt”, com todos os seus recursos, e nada mais. — No fundo, estou usando “dpkg” + “apt”, com a vantagem de poder pesquisar facilmente, no Histórico do Synaptic, quando determinado pacote foi instalado, atualizado, removido.

O Synaptic do Linux Mint é “diferente”, desde há muitos anos. — Desta vez, percebi mais uma alteração: — Agora, ao clicar em “Repositórios”, ele abre o Software Sources.

Isso me dá controle dos pacotes que instalo, atualizo ou removo, nas distros de base “.deb”. — Em certos casos, como escolher “espelhos”, mudar de Kernel, ou gerenciar drivers, é ótimo dispor das ferramentas do Mint. — No Synaptic, remover Kernels antigos é mais trabalhoso do que pelo mintUpdate, pois é preciso lembrar de fazer isso, procurá-los, marcá-los manualmente, verificar se não cometi algum erro, aplicar etc.

2025-07-16 - 21:00 - Aceitei que o Update Manager fizesse a atualização geral — na crença de que iria tudo para o Histórico do Synaptic (copiável), como em 2020. — Não foi!

Os registros em “/var/log/apt” indicam que o mintUpdate deixou de usar o Synaptic em modo CLI — e passou a usar o AptKit:

mintUpdate's footprints within /var/log/apt/history.log, back in 2020:

Start-Date: 2020-06-12  19:38:59
Commandline: /usr/sbin/synaptic --hide-main-window --non-interactive --parent-window-id 62918213 -o Synaptic::closeZvt=true --set-selections-file /tmp/tmpiqnq3566
Requested-By: flavio (1000)
Install: linux-image-5.4.0-37-generic:amd64 (... ... ...)
Upgrade: evolution-data-server-common:amd64 (... ... ...)
End-Date: 2020-06-12  19:43:33

mintUpdate's footprints within /var/log/apt/history.log, nowadays:

Start-Date: 2025-07-16  21:02:05
Commandline: aptkit role='role-install-packages' sender=':1.85'
Install: linux-modules-6.8.0-63-generic:amd64 (... ... ...)
Upgrade: openvpn:amd64 (... ... ...)
End-Date: 2025-07-16  21:09:54

Daí em diante, utilizei o Synaptic para instalar seu indexador apt-xapian-index (filtro rápido), além dos pacotes do Conky, aha, html2text, htop, ttf-mscorefonts-installer, Tasksel, gnome-screenshot etc.

2025-07-16 - 22:30 - Instalei pelo Synaptic o meta-pacote KDE Plasma Desktop (495 pacotes), depois de me certificar de que não incluía nenhum pacote com nome contendo “PIM” ou “Akonadi”. — Durante a instalação, o Synaptic perguntou qual Display Manager deveria ser padrão. Troquei o LightDM pelo SDDM. — O processo todo durou menos de 2 minutos. Reiniciei e entrei no KDE Plasma.

Linux Mint com KDE Plasma

2025-07-16 - 22:39 - O KDE Plasma já iniciou com as configurações “herdadas” via partição “Home10”. — O ajuste mais urgente foi a troca dos caminhos (PATH) “/run/media/$USER” por “/media/$USER” — no Dolphin, no Conky, nos atalhos do gnome-screenshot, e em um script que uso para registrar informações da distro 5 minutos após o boot.

Adiei a remoção do PackageKit, Plasma Discover, para fazer mais algumas observações — e enquanto isso, vou convivendo com 3 notificações quase permanentes na bandeja do sistema.

Também adiei a remoção do Xfce — que só fui fazer em Outubro.

Configuração do KDE Neon

Ajustes iniciais nas configurações do KDE Neon

O KDE Neon “herdou”, na partição “Home5”, as configurações de uma instalação anterior dele mesmo, ainda com Plasma 5. — Em casos assim, preciso redirecionar o lançador do System Settings (no Painel, no Menu) para o novo nome do pacote no Plasma 6 — e remover ou trocar alguns widgets (Moon, Weather) por versões Qt6.

O Plasma 6 costuma manter as configurações que venho fazendo há anos, no Plasma 5, o que poupa muito trabalho — mas o Wayland bagunça as regras de janela do Kwin criadas no X11 — por isso, tratei de estabelecer o Login Automático em sessão X11.

Primeiros ajustes no Conky do KDE Neon

Pelo apt, instalei o Synaptic; e por ele instalei seu indexador apt-xapian-index; e os pacotes do gnome-screenshot, Conky, Neofetch (que trouxe o ImageMagick), screenFetch (que trouxe o scrot), inxi (que trouxe o tree), htop, html2text, ttf-mscorefonts-installer, KWrite, binutils, Tasksel, KRename, Midnight Commander (mc), e assim por diante.

Pelo KRunner, iniciei as 2 instâncias do Conky, para verificar os ajustes do lm-sensors, hwmon, fontes, partições etc.

Instalei o Google Chrome usando o mesmo pacote baixado antes, no Kubuntu, e já reaproveitado para instalar no Linux Mint — pelo comando dpkg — e isso configura seu repositório no processo:

$ sudo dpkg -i google-chrome-stable_current_amd64.deb

Extraindo Log's legíveis

Extraindo uma cópia legível de logs do apt

O log do apt é meu principal recurso para recuperar informações exatas de quais pacotes atualizei ou instalei antes de começar a usar o Synaptic — indicando, inclusive, quais comandos foram usados, e por “quem”.

A instalação do Linux Mint, por exemplo, foi feita por “mint (1000)”, das 22:12 às 22:20 — enquanto a instalação do Synaptic foi feita por mim, 3 dias depois, às 20:41, usando o comando “/usr/bin/apt” — mas a primeira atualização foi feita pelo Update Manager, usando o comando “aptkit”, das 21:00 às 21:09.

Acontece que o log do apt usa linhas quilométricas, de mais de 10.000 caracteres, o que dificulta a leitura. — Usei o comando “sed” para quebrar as linhas ao final do nome de cada pacote — que sempre termina com parêntesis, vírgula, espaço:

sed 's/), /)\n/g' a.txt > b.txt

Nas 3 distros, o log inicial foi comprimido para “history.log.1.gz” no dia 27 Julho, talvez porque atualizo minhas distros aos Domingos. — Copiei o conteúdo de cada um desses arquivos, salvei como “a.txt” — e obtive a cópia legível em “b.txt”.

Isso não inclui o Google Chrome, que instalei pelo dpkg, um nível abaixo do apt. — Então, busquei essa informação no log do dpkg:

Start-Date: 2025-07-16  21:40:32
Commandline: /usr/sbin/synaptic
Requested-By: flavio (1000)
Install: python3-distupgrade:amd64 (1:24.04.26, automatic)
ttf-mscorefonts-installer:amd64 (3.8.1ubuntu1)
ubuntu-pro-client-l10n:amd64 (36ubuntu0~24.04, automatic)
update-manager-core:amd64 (1:24.04.12, automatic)
python3-distro-info:amd64 (1.7build1, automatic)
python3-update-manager:amd64 (1:24.04.12, automatic)
python3-debconf:amd64 (1.5.86ubuntu1, automatic)
ubuntu-release-upgrader-core:amd64 (1:24.04.26, automatic)
update-notifier-common:amd64 (3.192.68.2, automatic)
ubuntu-pro-client:amd64 (36ubuntu0~24.04, automatic)
End-Date: 2025-07-16  21:41:04

--------------------------------------------------------------------------------
2025-07-16 21:56:01 status installed google-chrome-stable:amd64 138.0.7204.157-1
2025-07-16 21:56:01 status installed mailcap:all 3.70+nmu1ubuntu1
2025-07-16 21:56:01 status installed gnome-menus:amd64 3.36.0-1.1ubuntu3
2025-07-16 21:56:01 status installed desktop-file-utils:amd64 0.27-2build1
2025-07-16 21:56:02 status installed man-db:amd64 2.12.0-4build2
--------------------------------------------------------------------------------

Start-Date: 2025-07-16  22:06:07
Commandline: /usr/sbin/synaptic
Requested-By: flavio (1000)
Install: tasksel-data:amd64 (3.75ubuntu1, automatic)
tasksel:amd64 (3.75ubuntu1)
End-Date: 2025-07-16  22:06:08

O log do dpkg não tem linhas quilométricas — mas apresenta muitas linhas intermediárias. — Para extrair só as que interessam, uso outro comando:

cat a.txt | grep 'status installed' > b.txt

Atualização do “linux-firmware”

Falha ao atualizar o pacote “linux-firmware” no Kubuntu e no KDE Neon

No Domingo, 7 Set. 2025, o apt / Synaptic do Kubuntu não conseguiu baixar uma atualização do repositório oficial “archive.ubuntu.com”:

W: Failed to fetch http://archive.ubuntu.com/ubuntu/pool/main/l/linux-firmware/linux-firmware_20240318.git3b128b60-0ubuntu2.17_amd64.deb
  500  Internal Server Error [IP: 2620:2d:4002:1::102 80]

No entanto, o apt / Synaptic do Linux Mint já tinha baixado essa atualização, sem nenhum problema — porque, nele, eu havia configurado o espelho (mirror) “ubuntu.c3sl.ufpr.br”.

Quando falha o repositório de 1 distro, eu normalmente passo adiante, continuo atualizando as outras, e volto a tentar mais tarde.

Mas este caso é especial: — Três distros com a mesma base “Ubuntu LTS” — que deveriam se comportar do mesmo modo, nessa área.

Pesquisei, e o Google encontrou vários relatos dessa falha, nos fóruns do Ubuntu e do Mint — com indicações de que já durava dias.

Download do pacote .deb para “/var/cache/apt/archives/”

Eu não gosto de alterar repositórios / espelhos, só para atender alguma emergência temporária. — Além disso, o Mint, o KDE Neon e o Kubuntu usam padrões diferentes nas configurações dos repositórios, o que dificulta examinar os detalhes com calma, para evitar erros. — Continuei pensando no assunto, enquanto atualizava as outras distros, e acabei optando por apenas baixar o pacote do espelho que estava funcionando, e copiá-lo para o “cache de pacotes” do Kubuntu e do KDE Neon:

$ history
  (...)
  990  2025-09-07_17-27-47 sudo chown 0:0 linux-firmware_20240318.git3b128b60-0ubuntu2.17_amd64.deb
  992  2025-09-07_17-29-31 sudo cp linux-firmware_20240318.git3b128b60-0ubuntu2.17_amd64.deb /media/Linux8/var/cache/apt/archives/
  994  2025-09-07_17-30-42 sudo cp linux-firmware_20240318.git3b128b60-0ubuntu2.17_amd64.deb /media/Linux5/var/cache/apt/archives/

Depois disso, bastou abrir o Synaptic no Kubuntu e no KDE Neon, e mandar atualizar.

Upgrade do Mint 22.1 Xia para 22.3 Zena

Erro no espelho (mirror) da UFPR, indicado pelo apt update

Janeiro 2026 - Já faz tempo que desabilitei as verificações automáticas do Update Manager (mintUpdate) — e também removi seu ícone do Painel — para não ficar exibindo alertas, toda vez que faço minha verificação manual pelo apt update, em geral aos Domingos.

Pesquisa e cópia no Histórico no gerenciador de pacotes Synaptic

Como disse antes, eu costumo executar o apt update para “ver” os pacotes atualizáveis — e também para “ver” o estado da conexão e dos espelhos (mirrors) — para depois atualizar tudo pelo Synaptic, que guarda um ótimo Histórico, copiável e pesquisável.

Copiar para um arquivo TXT permite consultar, mesmo “de fora” — quando estou em outra distro.

Foi assim que, no dia 11, “vi” uma falha do apt, com a sugestão de que o espelho poderia estar no meio de uma sincronização. — Meia-hora depois, tentei de novo, mas o erro continuava. — Prossegui com minha atualização semanal das outras distros.

No dia 12, várias postagens nas redes sociais avisaram do lançamento do Mint 22.3 “Zena” — e já seria o 2º upgrade, desde quando instalei o Mint 22.1 “Xia”. — Eu não tinha feito o 1º, porque o mecanismo de upgrade do Mint não é feito (e não é testado) para o KDE Plasma.

Eu já tinha pensado nessa incerteza, em minha instalação anterior do Linux Mint (2020). — Agora, resolvi experimentar, para ver o resultado.

Aviso do Update Manager de que precisava atualizar “mint-upgrade-info”

No dia 14, abri o Update Manager e fui avisado de que uma nova versão do “Update Manager" estava disponível. — O único pacote citado era “mint-upgrade-info” (informações de upgrade). — E propunha “aplicar a atualização”. Mas, qual, exatamente?

As “lojinhas” são ótimas para o novato. — Você pode confiar no Mint — e não precisa responder perguntas embaraçosas. — Mas eu quero saber o que está acontecendo — e guardar anotações claras.

Fechei o Update Manager. Ele só minimizou para o Painel. Recorri à opção “Quit” para fechá-lo de verdade, para ter certeza de desbloquear o banco de dados. — Executei um apt update, conferi que o espelho (mirror) estava Ok — e usei o Synaptic para atualizar 47 pacotes, inclusive o “mint-upgrade-info” (o Update Manager não foi atualizado).

Deve-se fazer uma atualização completa do sistema (qualquer sistema), antes de fazer upgrade para nova versão.

Opções de Snapshots e de Upgrade de versão, no Update Manager

Reiniciei o Linux Mint, abri de novo o Update Manager — ele declarou que estava tudo atualizado. — Abri o menu “Edit”, para acessar as ferramentas “Instantâneos do sistema” (Timeshift) e “Fazer upgrade para Mint 22.3 Zena”.

Não vi opção de escalonar o upgrade em 2 etapas — de 22.1 para 22.2 — e depois, de 22.2 para 22.3.

Direcionei o “instantâneo” para a partição “Midia”, onde havia espaço de sobra. — A ocupação passou de 75 GiB para 85 GiB.

Upgade do Linux Mint exigiu reinstalar o meta-pacote Xfce

Na etapa "Requisitos”, o Update Manager exigiu instalar o pacote “mint-meta-xfce” antes de fazer o upgrade. — Depois, marcar “Entendo os riscos”. Não se pode processar quem nos dá um ótimo sistema operacional de graça. — É seguro, desde que a gente não faça bobagem.

O upgrade demorou cerca de 5 minutos — incluindo uma pausa para decidir se eu deixaria substituir uma configuração de início automático do Mint Report. — Optei pelo “não”, com a certeza de que ficaria um backup da proposta recusada (como, de fato, ficou).

PrtScn                                          apt/history.log

19:39:18 - installing Xfce Meta Package              - 19:39:18
19:39:50 - update Packages Cache
19:40:09 - installing packages                       - 19:41:58
19:42:56 - replace /etc/xdg/autostart/mintreport ?
19:44:14 - removing packages                         - 19:44:12
19:44:23 - Upgrade Complete                          - 19:44:13

Para preencher a lacuna no meu TXT com o histórico do Synaptic, acabei usando um comando unificado:

cat /var/log/apt/history.log | sed 's/), /)\n/g' > apt-history-log.txt

Várias coisas voltaram às configurações-padrão:

O Synaptic foi removido — mas seu Histórico foi mantido. — Reinstalei.

O “apt” voltou aos repositórios originais. — Tive de configurar de novo espelhos locais.

xxxx

Mudando a /home para XFS

Verificação da cópia da pasta do usuário para outra partição

Uso o sistema de arquivos XFS na partição /home do openSUSE há mais de 8 anos, desde Janeiro 2017, e nunca tive qualquer problema. — Pelo contrário, são minhas partições /home em sistema de arquivos ext4 que às vezes acumulam problemas, após alguns desligamentos abruptos por queda da rede elétrica na minha rua. — Resolvi converter a partição “Home5”, do KDE Neon, para XFS, como experiência-piloto.

Copiei a pasta de usuário do KDE Neon para uma partição que estava vazia, utilizando o Midnight Commander, que preserva as propriedades dos arquivos e pastas. — Por via das dúvidas, conferi a cópia com o original, usando o “Compare” do Krusader.

Em geral, essas operações devem ser feitas em uma sessão Live — pois a pasta de usuário não pode estar em uso (montada). — Uma vantagem de ter outras distros em dualboot / multiboot, é poder usar uma delas, já configurada e com todas as ferramentas instaladas, o que é bem mais confortável.

Desmontei a partição “Home5” e formatei para XFS, pelo KDE Partition Manager — e copiei de volta a pasta de usuário. — Editei o /etc/fstab do KDE Neon, com o novo UUID da partição “Home5”, e ele continua funcionando normalmente, após 11 dias.

Depois de me certificar de que deu tudo certo, converti também a partição Home2, do Arch Linux, para XFS — e deixo aberto o caminho para fazer a conversão das demais partições /home no futuro.

Final, finais

Formatando a partição do KDE Neon para instalar o PCLinuxOS

2025-09-22 - Ao instalar uma nova ISO do PCLinuxOS KDE Darkstar 2025-09, precisei de uma partição com 30 GiB (ou menos). — Tentei “encolher” (shrink) a partição Linux11, que tem 60 GiB, mas o GParted da sessão Live acusou “erro”, e não permitiu. — Optei por sobrescrever a partição Linux5, e com isso deletei a instalação do KDE Neon, que considerei mais “dispensável” do que o Kubuntu LTS ou o Mint (com KDE).

xxxx

___________________
• Publicado em 1º Agosto 2025; e desenvolvido até...

— … ≠ “•” ≠ … —

PC desktop UEFI / GPT

Ferramentas &tc.

O Neofetch parou? Viva o Fastfetch!

Multi-boot de 12 distros Linux

Grub enlouquecido com 12 distros em multiboot

Fedora 42 KDE - instalação e configuração

noreply@blogger.com (Mboaba) — Thu, 24 Apr 2025 02:33:00 +0000

Fedora 42 com algumas configurações “herdadas” do Plasma 5 (de outra distro)

• Eu já tinha o Fedora. — Instalei a versão 31, no início de 2020, e vim atualizando para 32, 33, 34, 35, 36, 37, 38, 39, 40, 41 — mas esses upgrades nem sempre incorporam certas novidades, que só são vistas em uma instalação nova.

Esta semana, um colega novato em “Linux” instalou o Fedora 42, pediu ajuda em um Fórum, e ao longo da conversa percebi o quanto eu estava alheio às novidades dessa distro. — A revisão do Jesse Smith no Distrowatch atiçou ainda mais a minha curiosidade — e decidi fazer uma instalação nova, para ver como andam as coisas atualmente.

Porém, sem deletar a instalação antiga. O Fedora 41 está configurado do meu jeito, com os aplicativos de que preciso — e pretendo fazer upgrade dentro de 2 ou 3 semanas. — Nenhum motivo para jogar fora.

Optei por fazer a instalação nova em outra partição — afinal, tenho 12 partições para isso, rotuladas de “Linux1” a “Linux12” — e 4 delas estavam vagas. — Escolhi a partição “Linux8”.

Fedora 42 na partição “Linux8” — e o 41 em “Linux4”

A instalação nova ocupou 7,4 GiB em disco — e depois de instalar alguns softwares (total: 2.327 pacotes), chegou a 8,84 GiB — enquanto a instalação de 2020 já ocupa 19,3 GiB (total: 3.081 pacotes).

Reutilizei a partição “Home8” (de uma distro que usava Plasma 5), e o Fedora 42 “herdou” suas configurações — inclusive o applet Quick Launcher (junto ao Menu), que não consigo configurar no Plasma 6. — Até hoje, consegui apenas mantê-lo, nas distros que tinham o Plasma 5 e migraram para o Plasma 6.

Índice

Download

Hardware

Sessão Live

Instalação

Partições EFI e bootloaders

Um bug amplamente benigno

Testando os “bootloaders”

Configuração

Remoção da distro instalada

Download

Verificação da imagem ISO do Fedora 42 KDE pela soma sha256sum

Baixei a imagem Fedora-KDE-Desktop-Live-42-1.1.x86_64.iso (2,6 GiB), datada de 2025-04-09 12:34, além do arquivo de verificação. — Conferi pelo sha256 — e “queimei” no Pendrive pelo comando dd:

$ lsblk
NAME    MAJ:MIN RM   SIZE RO TYPE MOUNTPOINTS
sda       8:0    0 447.1G  0 disk
├─sda1    8:1    0     2G  0 part /boot/efi
.........
sdc       8:32   1   7.5G  0 disk
└─sdc1    8:33   1   7.5G  0 part /run/media/flavio/PENDRIVE2

$ sudo dd bs=4M if=/PATH/Fedora-KDE-Desktop-Live-42-1.1.x86_64.iso of=/dev/sdc conv=fsync oflag=direct status=progress

2839543808 bytes (2.8 GB, 2.6 GiB) copied, 297 s, 9.6 MB/s2844538880 bytes (2.8 GB, 2.6 GiB) copied, 297.61 s, 9.6 MB/s

678+1 records in
678+1 records out
2844538880 bytes (2.8 GB, 2.6 GiB) copied, 297.697 s, 9.6 MB/s

Reiniciei o computador, entrei no UEFI Bios Utility, selecionei boot pelo Pendrive, e apareceu o Grub da ISO. — Carreguei a sessão Live Fedora 42 KDE sem perder tempo verificando (de novo) sua integridade.

Hardware

  MoBo: TUF B360M-PLUS GAMING/BR - ASUSTeK
   CPU: 6 × Intel® Core™ i5-9400 CPU @ 2.90GHz (800 ~ 4100 MHz)
  iGPU: Intel UHD Graphics 630 (Desktop)
   RAM: 15.5 GiB of RAM
   SSD: Kingston   SA400S37480G      480 GB
   SSD: WD         WD Green 2.5      480 GB

Sessão Live

Uso de Memória RAM na sessão Live Fedora 42 KDE

A sessão Live do Fedora 42 KDE começou usando 1,86 ~ 1,88 GiB de Memória RAM (1.909 ~ 1.921 MiB), segundo o top, executado em console virtual (tty4) para não abrir o Konsole (GUI) — pois isso aumentaria o uso de RAM. — Abrir o Plasma System Monitor (GUI) elevou o uso de RAM para 2,0 GiB.

Uso de Memória RAM durante a sessão Live Fedora 42 KDE

Com Dolphin, KWrite, Gwenview, Konsole, System Settings, Welcome Center, Firefox, System Monitor abertos ao mesmo tempo, este último indicou uso de 4,0 a 4,3 GiB de Memória RAM, em diferentes momentos da sessão Live — e depois de abrir também o instalador Anaconda (versão tradicional), o uso de RAM subiu para 5,0 GiB. — Ao fechar o Anaconda, no final, o uso de RAM voltou a 4,3 GiB.

Vale lembrar que o Pendrive contém um sistema operacional compactado — e a sessão Live precisa descompactá-lo para a Memória. — Por isso, é normal uma sessão Live usar mais RAM do que o mesmo sistema instalado em disco.

Não percebi qualquer lentidão, em nenhum momento — e não vejo como poderia ocorrer qualquer troca de dados entre RAM e Swap, pois o Fedora Live não montou minha partição Swap — e não utilizou o Swap de 8 GiB que criou em zRAM.

Seção ilegível do Instalador, com tema Dark

Talvez eu tenha cometido algum erro, ao aplicar o tema global Breeze Dark, pois mais tarde me deparei com telas ilegíveis (letras pretas sobre fundo escuro) na seção de particionamento personalizado do instalador. — Reverti para um tema claro, mas só fez efeito depois de fechar o instalador, reabrir, e começar tudo de novo.

Instalação

O instalador do Fedora 42 KDE Live ainda era o Anaconda “tradicional”

A ISO do Fedora 42 KDE Live veio com o instalador Anaconda “tradicional” — ao contrário da ISO “Workstation” (Gnome), que agora vem com um “Anaconda Web UI” — uma nova interface (1, 2, 3).

Menu e seções do instalador Anaconda “tradicional”

O Anaconda “tradicional” segue o modelo “hub and spoke” (concentrador e raios), para acesso a várias seções — Teclado, Data & Hora, Rede & Nome de Host, conta Root, Criação de Usuário, e Destino da Instalação. — Você pode percorrer esses “raios” em qualquer ordem, quantas vezes quiser, mudando e tornando a mudar as configurações em cada uma das seções que irradiam do “centro” — mas só pode prosseguir quando todas as 6 seções estiverem adequadamente configuradas (desaparecem o triângulo e os alertas em vermelho, de todas elas).

Percebi poucas diferenças em relação ao que registrei em meados de 2019, ao instalar o Fedora 30 no meu antigo computador (Bios / MBR) — ou em 2020, ao instalar o Fedora 31 no meu PC atual (UEFI / GPT). — Agora, propõe esquema de pontos de montagem BtrFS em vez de LVM (optei por particionamento padrão).

Desta vez, a escolha do layout de Teclado não foi tão óbvia, para mim. — Minha primeira opção mostrou-se totalmente errada, quando fui preencher algum outro campo, e apareceu uma sopa de letrinhas absurdas. — Voltei à seleção do Teclado, e dessa vez tratei de testar (do lado direito da tela), para ter certeza de que escolhi o layout certo.

Mudando do particionamento Automático para o Personalizado

Na seção de particionamento, selecionei meu 2º SSD (WD Green) — que tinha apenas 3 distros instaladas.

Eu sempre opto pelo particionamento “Personalizado” — pois preparo minhas partições com antecedência, e quero apenas escolher quais pretendo usar para /, /home, EFI, Swap.

Troquei BtrFS pelo particionamento padrão (tradicional)

A criação de pontos de montagem do Fedora 42 veio configurada para usar esquema BtrFS — mas já tenho isso no openSUSE (desde 2017, sem qualquer problema) — e prefiro manter todas as outras distros com o esquema padrão de particionamento.

Eu uso qualquer distro para olhar ou editar alguma coisa nos arquivos de sistema das outras — o que é mais cômodo do que usar uma sessão Live, para isso — mas é difícil (e perigoso) lidar com a árvore de arquivos do BtrFS “desmontada”.

O instalador “agrupa” as partições que pertencem a alguma distro já instalada. — Notei que detectou o Mageia e o MX Linux (identificado como Debian) — mas não o Void Linux, que também estava neste SSD.

Concluídas as opções do particionamento, um alerta do que será formatado

Após selecionar as partições /, /home e EFI a serem usadas na instalação do Fedora 42, o instalador Anaconda ainda não permitia seguir adiante. — É preciso marcar a partição de sistema "/" para ser formatada, mesmo que já esteja pronta e vazia.

As partições /home e Swap são opcionais — e acabei esquecendo de configurar a partição Swap.

Para /home, selecionei minha partição “Home8”, de uma distro já deletada, que usava Plasma 5. — Optei por não formatar, para reaproveitar as configurações de usuário existentes nela.

Escolhi minha 2ª partição EFI, localizada no 2º SSD

Selecionei minha 2ª partição EFI (sdb16). — Ela tem rótulo (label) “EFI2" — mas isso é irrelevante, e nem aparece. — A depender da ferramenta utilizada, ela pode ser identificada como “WD Green”, ou como “HD(16,GPT,bae...” etc.

Cuidado para não formatar a partição EFI, que contém os bootloaders de outras distros instaladas antes. — De qualquer modo, ao tentar prosseguir, o instalador Anaconda “tradicional” ainda mostra um resumo das partições que serão formatadas. — É possível voltar atrás, para corrigir. — O instalador “novo” não dá essa chance. Dizem que é um destruidor instantâneo.

A etapa seguinte, de cópia de arquivos (Pendrive para SSD) e instalação efetiva, se completou em 8 minutos.

Partições EFI e bootloaders

Bootloaders vistos pelo efibootmgr ao terminar a instalação do Fedora 42 KDE

Ao terminar a instalação do Fedora 42 KDE, o comando efibootmgr da sessão Live indicava que o boot tinha sido feito pelo “bootloader” do Pendrive, identificado naquele momento pelo nº hexadecimal 11 — e que, agora, a prioridade de boot era do “bootloader” nº 02 “Fedora”, instalado na 2ª partição EFI — “HD(16,GPT,bae...” etc. (sdb16, ou “WD Green”).

Nenhum sinal do “bootloader” do Fedora 41 — que antes era o nº 02.

Lista (virtual) dos bootloaders, antes e depois de instalar o Fedora 42 KDE

Ao reiniciar o computador (sem o Pendrive) e acessar o UEFI Bios Utility, o firmware já tinha feito nova leitura das partições EFI e apresentou um inventário aumentado de 9 para 10 “bootloaders” — com o Fedora 41 no final (abaixo do Fedora 42) — e os demais deslocado para cima.

Isso não tem nada a ver com a época em que foram criados, nem com a ordem de prioridade de boot. — Esse “inventário” exibido pelo UEFI Bios Utility da minha placa-mãe serve apenas para escolher qualquer “bootloader” e teclar Enter para usá-lo (só por esta vez). — Costuma apresentar no final os que foram “modificados” por último.

Resposta do efibootmgr após reiniciar o computador

Carreguei uma das distros instaladas, tornei a executar o efibootmgr e ele confirmou que o “bootloader” do Fedora 42 passou a ser o nº 02 — enquanto o do Fedora 41 tornou-se o nº 11. — Faltam vários números (03, 05, 07, 08, 0A, 0B, 0E, 0F), de alguns “bootloaders”, obsoletos, que eu tinha eliminado dias antes — e dos “bootloaders” permanentes (DVD, Pendrive, Rede), que não foram listados (não me pergunte porquê).

Esses números hexa não parecem estar “dentro” desses “bootladers”, pois a pasta do Fedora 41 não foi modificada nesse dia (21 Abril 2025). — Imagino que sejam atribuídos pelo firmware, e não sei onde são guardados. Na ROM? PROM? EPROM? EAROM? EEPROM? — Ou é apenas a “lógica” do firmware que atribui sempre os mesmos números, fazendo-os parecer “fixados”?

Localização “física” dos “bootloaders” nas 2 partições EFI; e datas de modificação

Também não têm nada a ver com a ordem em que os “bootloaders” foram modificados — nem com a ordem de localização “física” em disco, que corresponde à sequência original em que instalei as distros, em 2020: — PCLinuxOS, depois openSUSE, Fedora, KDE Neon (removido), Debian, e por fim a criação manual do atual “bootloader” do Arch Linux em 2023 (havia outros, que deletei em várias épocas).

Sem o parâmetro “-U”, o comando tree mostraria por ordem alfabética.

Na EFI2, a ordem “física” em disco corresponde à sequência em que gerei manualmente os “bootloaders” do MX Linux, Mageia, Void Linux, há poucos dias — e agora, a instalação nova do Fedora 42.

Ignore o bootloader “MX”, que criei só para testar o novo aplicativo UEFI Manager (GUI) do MX Linux. — Não me interessou, e já deletei.

Só houve alterações na partição EFI2

Portanto, as únicas alterações feitas pela instalação do Fedora 42, no dia 21 Abril 2025, ocorreram na partição “EFI2” — criação das pastas “BOOT”, “Fedora”, “System/Library” e arquivo “mach_kernel”. — Nada disso existia antes.

Ver “Criando uma 2ª partição EFI”, aqui.

Um bug amplamente benigno

Excesso de “bootloaders” em nova sessão Live — sem efeito real, ao reinicializar

Houve um princípio de alarmismo com um bug em algumas imagens ISO — que andaria gerando um “bootloader” do Fedora 42, mesmo que a distro acabe não sendo instalada — e o alerta de bug parece contribuir, mais para assustar, do que para esclarecer:

«As imagens afetadas adicionarão uma entrada inesperada à lista do gerenciador de inicialização UEFI assim que a mídia for inicializada, mesmo que você não instale o Fedora. A nova entrada é adicionada ao topo da lista (portanto, é a primeira prioridade na inicialização). A entrada é intitulada "Fedora" e tenta inicializar a mídia live do Fedora».

Na verdade, essa “lista do gerenciador de inicialização UEFI” é volátil — reunida num determinado momento (a partir da leitura dos dispositivos detectados), para ser exibida e usada naquele instante — e evapora quando o computador é desligado.

O que permanece são os “bootloaders” gravados em uma ou várias partições EFI — inclusive a do Pendrive (enquanto estiver plugado).

Executei uma nova sessão Live (depois de instalar o Fedora 42), e o efibootmgr apresentou mais 2 “bootloaders” — “Fedora” (nº 3) e “VendorCoProductCode” (nº 13) — além dos “Fedora” que já estavam instalados (nº 2, nº 11).

Mas ao encerrar a nova sessão Live e reiniciar o computador (sem o Pendrive), permaneceram apenas os “bootloaders” correspondentes às duas instalações em disco. — Tudo indica ser este o comportamento amplamente benigno (na maioria dos casos).

O alerta de bug diz que em alguns (poucos) casos, o “bootloader” do Live Pendrive “fica” no computador — mas se o Pendrive não estiver mais plugado, não afetará o sistema. — Não tive essa experiência.

Testando os “bootloaders”

A Swap zRAM se alastrou para minha instalação antiga do Fedora, em dualboot

Minha primeira preocupação, após a instalação nova do Fedora 42 (nas partições Linux8 e EFI2) foi testar o “bootloader” da minha instalação antiga do Fedora 41 (partições Linux4 e EFI).

Reiniciei o PC, escolhi o “bootloader” nº 11 — ele chamou o Grub do Fedora 41 — e carregou o Fedora 41.

A surpresa ficou por conta do Swap, que era de 11 GiB (em sda13) — e agora pulou para 19 GiB — com o acréscimo dos 8 GiB zRAM, configurados pelo instalador do Fedora 42.

Não perdi tempo tentando entender como a instalação nova conseguiu afetar a instalação antiga (em um SSD que não foi modificado). — Removi o pacote zram-generator, conforme sugerido pelo Jesse Smith — e o Fedora 41 voltou a usar só os 11 GiB da partição Swap.

Quanto ao Conky sem gráficos, é um problema que só tenho naquela instalação antiga do Fedora — a única em que uso sessão Wayland (para ver como se comporta). — Fiz recentemente um teste de uso de 7 dias, e nesse período o Conky deixou de exibir os gráficos (e voltou a exibi-los após algumas horas), pelo menos 5 vezes.

Testei mais alguns “bootloaders”, e todos funcionaram como esperado. — As outras distros continuaram montando apenas a Swap de 11 GiB (sda13) — que só vi ser usada 1 vez, em mais de 5 anos.

Atualização do Grub para incluir a instalação nova do Fedora 42

Enfim, atualizei o Grub do openSUSE — meu “Menu de inicialização” — para detectar e incluir a instalação nova do Fedora 42 na partição “Linux8”.

Configuração

Ajustes necessários para reaproveitar configurações “herdadas” na /home

Ao iniciar uma distro recém-instalada — com as configurações de uma partição /home “herdada” de outra distro (sempre com KDE) — aproveito o papel de parede, Painel, widgets, montagem automática de partições etc.

Mas sempre faltam alguns ajustes, a serem feitos com urgência — para poder começar a documentar as demais configurações, o mais cedo possível. — Não vejo muito interesse em detalhá-las:

Autorizar a montagem automática de partições “adicionais”, sem exigir senha. — Sem isso, a montagem automática não pode funcionar. — Não é um “bug” do KDE System Settings. É um requisito lógico
Corrigir alguns “lançadores rápidos” (Quick Launch) — chamar “systemsettings” em vez de “systemsettings5”, por exemplo
Eliminar widgets que só funcionavam no Plasma 5 — Weather, Moon Phase, no meu caso — ou trocá-los por outros, que funcionem no Plasma 6
Configurar o KDE Spectacle para pular o diálogo — salvar logo as capturas de tela, com nomes no padrão “<yyyy>-<MM>-<dd>_<HH>-<mm>-<ss>_F42.jpg” (por exemplo) — e trocar sua notificação visual por um aviso sonoro
Instalar o Chrome — cujo “lançador rápido” aparecia em branco no Painel
Instalar o Conky — que já está no Autostart — e ajustar seus arquivos de configuração
etc.

Habilitar repositórios de terceiros, no Welcome Center

Alertado por uma conversa em um fórum, testei o botão “Habilitar repositórios de terceiros”, no Welcome Center — e confirmei que ele habilita um conjunto de repositórios tão arbitrários como os do Google, só para o Chrome; do RPM Fusion, apenas “Nonfree”, só para NVIDIA e Steam; e Copr, especificamente para PyCharm. — Não me interessou esse conjunto, cuja “lógica” me pareceu irracional; e tornei a desabilitá-lo, logo após essa verificação.

Em vez disso, baixei o pacote RPM do Chrome, diretamente do site do Google — instalei pelo comando dnf — e foi automaticamente adicionado (só) o repositório do Google Chrome:

$  sudo dnf install google-chrome-stable_current_x86_64.rpm

Antes de instalar mais e mais aplicativos, aproveitei para salvar em arquivos TXT a lista dos pacotes instalados até aquele momento — por ordem cronológica (inversa) e por ordem alfabética:

$  rpm -qa --last > rpm-qa-last.txt

$  rpm -qa | sort > rpm-qa-sort.txt

Autorização para montar partições adicionais sem exigir senha

Pelo nano, criei um arquivo de sistema autorizando a montagem de partições adicionais pelo usuário comum (sem exigir senha) — e colei nele este conteúdo:

Create file:

$  sudo nano /etc/polkit-1/rules.d/90-udisks2.rules

Pasted:

// 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; } });

A partir desse momento, basta o usuário clicar no ícone de uma partição extra, no Dolphin, para ela ser montada, sem exigência de privilégios.

Configuração da montagem automática de partições no KDE System Settings

Isso é necessário para que o KDE faça a montagem automática de partições extras no início de cada sessão — utilizando o udisks2.

Eu chamo essas partições de “adicionais”, ou “extras”. — O KDE chama essas partições de “dispositivos removíveis” — porque não fazem parte do sistema, e por isso podem ser desmontados.

# dnf remove korganizer kmail akregator kaddressbook akonadi-server mariadb-common
     Transaction Summary:
      Removing:          79 packages
# dnf4 autoremove
# dnf clean all
     Removed 24 files, 19 directories. 0 errors occurred.
# dnf4 upgrade --refresh
# dnf4 install kate
# dnf4 install conky
# dnf4 install lm_sensors
# sensors-detect
# dnf4 install mc
# dnf4 install plasma-workspace-x11

Removi os principais pacotes do “Personal Information Management” (PIM), removi pacotes órfãos, limpei o cache de pacotes — atualizei o sistema (445 + 14 pacotes) — e instalei alguns pacotes mais urgentes (para mim), como Kate, Conky, lm_sensors, Midnight Commander (mc), Plasma Workspace X11.

Remoção do PIM: Personal Information Management

O PIM é um poderoso conjunto (suite) de ferramentas — especialmente útil em escritórios corporativos — mas não uso, e desde 2016 adotei a prática de removê-lo das distros que o instalam por padrão.

Adicionando fontes a partir de arquivos ttf

Pelo KDE System Settings, adicionei algumas fontes, a partir de arquivos ttf guardados em outra partição.

Configuração do Auto Login do KDE Plasma em sessão X11

Instalado o Conky, um Logout / Login do KDE acionou o Autostart de suas 2 instâncias, “herdado” com a partição /home — e fiz alguns ajustes em seus arquivos de configuração. — O visual não ficou bom, devido a incompatibilidades com o Wayland, ainda não superadas.

Configurei o SDDM para fazer Login Automático em sessão X11 — e ao reiniciar, o Conky finalmente exibiu o aspecto esperado.

Por enquanto, eu monitoro o comportamento do Wayland na instalação antiga do Fedora — onde é comum o Conky deixar de exibir os gráficos, e voltar a exibi-los após algumas horas. — Já registrei 5+ ocorrências em apenas 7 dias.

Instalei os repositórios RPM Fusion (Free e Nonfree), em seguida o VLC — e mais alguns pacotes que fui lembrando — inclusive o gnome-screenshot, que ainda não consegui usar com muito sucesso:

dnf4 install gnome-screenshot
dnf install https://download1.rpmfusion.org/free/fedora/rpmfusion-free-release-$(rpm -E
dnf install https://download1.rpmfusion.org/nonfree/fedora/rpmfusion-nonfree-release-$(rpm -E
dnf4 install vlc
dnf4 install kstars
dnf4 install yt-dlp
dnf4 install krename
dnf4 install fastfetch
dnf4 install inxi
dnf4 install htop
dnf4 install aha
dnf4 install html2text
dnf4 install gimp

Configurando o crontab para executar scripts após cada boot

Configurei o crontab para acionar scripts que registram informações 5 minutos após o início de cada sessão: — Data e hora do boot, uso inicial de Memória RAM, e as versões de vários softwares: — Kernel, init, Plasma, Qt, Frameworks etc.

Instalei Fastfetch, inxi, htop, aha, html2text, utilizados por esses scripts e pelo Conky — reiniciei o computador — e após 5 minutos (idle) da nova sessão, o script registrou uso de cerca de 1.700 MiB de RAM.

Redução gradual do uso de RAM do Fedora 42 KDE

Reiniciei mais 4 vezes o computador, e o uso inicial de Memória RAM foi diminuindo mais um pouco, até cerca de 1.400 MiB.

Desabilitei vários serviços em “Plasma Search” — Activities, Bookmarks, Browser History, Browser Tabs, Dictionary, File Search, Software Centre, Spell Checker. — No Discover, desabilitei Flatpaks e a notificação de atualizações.

Após remover o zram-generator e o PackageKit, o uso inicial de Memória RAM caiu até cerca de 1.300 MiB — nível que vem se mantendo até 5 Maio:

 Boot      Boot + 5min   (2025-04-22)

15:37        1.736 MiB
15:59        1.512 MiB
16:23        1.473 MiB
16:37        1.429 MiB
16:53        1.434 MiB
18:06        ----------- removed zram-generator
18:08        1.413 MiB
20:47        ----------- disabled some Plasma Search services
21:03        ----------- disabled Flatpaks & Discover notifications
21:05        1.400 MiB
21:21        ----------- removed PackageKit
21:25        1.306 MiB

Configuração e atualização do Grub do Fedora 42

O Fedora não atualiza seu Grub, ao instalar nova versão / revisão do Kernel. — No detalhe do alto, à direita, o arquivo grub.cfg ainda exibia a data e hora da instalação no computador. — As alterações só tinham sido feitas na pasta /boot/loader/entries — uma “novidade” do Fedora, que o Grub de outras distros ignora.

Em /etc/default/grub, desabilitei “Boot Loader Specification” (BLS) — e atualizei o arquivo grub.cfg, para que o novo Kernel seja “visto” pelo Grub do openSUSE — o “Menu de inicialização” do meu computador.

Também desativo os_prober em (quase) todas as distros, para não perderem tempo detectando as outras. — Basta que o Grub de cada uma gere entradas para seus próprios Kernels — para serem lidas pelo Grub do openSUSE (e pelo do Mageia, que é meu Grub de reserva).

Remoção da distro instalada

Upgrade da “instalação antiga” do Fedora 41 para 42

Ainda no final de Abril, fiz o upgrade da minha “instalação antiga” do Fedora 41 para 42 — mas mantive a “instalação nova” — para o caso de ainda querer verificar mais alguma coisa.

Formatando a partição “Linux8” com a “instalação nova” do Fedora

Por fim, em 1° Junho, deletei a “instalação nova”: — Para isso, formatei a partição “Linux8”, onde ela estava — mas não a partição “Home8”, que poderá ser aproveitada por outra distro, no futuro.

Deletando o “bootloader” na partição EFI2, pelo efibootmgr

Deletei seu “bootloader” na partição EFI2, usando o efibootmgr.

Grub atualizado, para eliminar a distro deletada

Enfim, atualizei o Grub do openSUSE, para retirá-la do Menu de inicialização.

___________________
• Publicado em 23 Abril 2025 e desenvolvido até 4 Junho 2025.

— … ≠ “•” ≠ … —

Fedora

PC desktop UEFI / GPT

Ferramentas &tc.

O Neofetch parou? Viva o Fastfetch!

Multi-boot de 12 distros Linux

Grub enlouquecido com 12 distros em multiboot

Neofetch parou? Viva o Fastfetch!

noreply@blogger.com (Mboaba) — Sun, 19 May 2024 13:10:02 +0000

Fastfetch configurado para ser mais legível e ocultar IP e outros dados

• “O Rei morreu, viva o Rei!” — porque não existe vácuo no mundo do software livre e de código aberto.

A notícia de que o desenvolvedor do Neofetch arquivou seu projeto no Github, em 26 Abril 2024, agitou os desenvolvedores de outros “fetch” — e levantou 2 questões, nos fóruns e comunidades:

Quais as alternativas? — e...

Por que alguém precisa de “fetch”?

Precisar, ninguém precisa — mas o bom da liberdade, é que cada um pode se divertir do jeito que quiser — e muita gente gosta de se divertir com algum “fetch”.

Sua utilidade é ilustrar uma captura de tela — onde cada um mostra sua Área de Trabalho, Wallpaper, informações do sistema, DE / WM, temas, fontes etc., de uma forma resumida e clara. — Há muitos fóruns ou comunidades onde milhares de pessoas se divertem trocando ideias sobre essas personalizações.

KInfoCentre: um resumo; — e Conky: controle em tempo real

Eu uso mais o KInfoCentre, que resume o hardware, a distro, a versão do Kernel, e os componentes do KDE Plasma — pois é com isso que eu me divirto: — KDE em distros rolling-release.

Para ter controle do que se passa, prefiro o Conky, com mil informações em tempo real — sem preocupações ornamentais.

E para pedir socorro em algum fórum, é mais adequada a saída de texto (não a imagem!) de um comando inxi, com as informações necessárias para que alguém possa ajudá-lo:

$ inxi -Fxz
System:
  Kernel: 6.6.32-1-lts arch: x86_64 bits: 64 compiler: gcc v: 14.1.1
  Desktop: KDE Plasma v: 6.0.5 Distro: Arch Linux
Machine:
  Type: Desktop Mobo: ASUSTeK model: TUF B360M-PLUS GAMING/BR v: Rev X.0x
    serial: [superuser required] UEFI: American Megatrends v: 2401
    date: 03/22/2019
CPU:
  Info: 6-core model: Intel Core i5-9400 bits: 64 type: MCP arch: Coffee Lake
    rev: A cache: L1: 384 KiB L2: 1.5 MiB L3: 9 MiB
  Speed (MHz): avg: 800 min/max: 800/4100 cores: 1: 800 2: 800 3: 800 4: 800
    5: 800 6: 800 bogomips: 34814
  Flags: avx avx2 ht lm nx pae sse sse2 sse3 sse4_1 sse4_2 ssse3
Graphics:
  Device-1: Intel CoffeeLake-S GT2 [UHD Graphics 630] vendor: ASUSTeK
    driver: i915 v: kernel arch: Gen-9.5 bus-ID: 00:02.0
  Display: x11 server: X.Org v: 21.1.13 with: Xwayland v: 24.1.0 driver: X:
    loaded: intel unloaded: modesetting dri: i965 gpu: i915
    resolution: 1920x1080~60Hz
  API: EGL v: 1.5 drivers: iris,swrast platforms:
    active: x11,surfaceless,device inactive: gbm,wayland
  API: OpenGL v: 4.6 compat-v: 4.5 vendor: intel mesa v: 24.1.1-arch1.1
    glx-v: 1.4 direct-render: yes renderer: Mesa Intel UHD Graphics 630 (CFL
    GT2)
  API: Vulkan Message: No Vulkan data available.
Audio:
  Device-1: Intel Cannon Lake PCH cAVS vendor: ASUSTeK driver: snd_hda_intel
    v: kernel bus-ID: 00:1f.3
  API: ALSA v: k6.6.32-1-lts status: kernel-api
  Server-1: JACK v: 1.9.22 status: off
  Server-2: PipeWire v: 1.0.7 status: off
  Server-3: PulseAudio v: 17.0 status: active
Network:
  Device-1: Realtek RTL8111/8168/8211/8411 PCI Express Gigabit Ethernet
    vendor: TP-LINK TG-3468 driver: r8169 v: kernel port: 3000 bus-ID: 03:00.0
  IF: enp3s0 state: up speed: 1000 Mbps duplex: full mac: [filter]
Drives:
  Local Storage: total: 894.26 GiB used: 327.56 GiB (36.6%)
  ID-1: /dev/sda vendor: Kingston model: SA400S37480G size: 447.13 GiB
  ID-2: /dev/sdb vendor: Western Digital model: WD Green 2.5 480GB
    size: 447.13 GiB
Partition:
  ID-1: / size: 29.36 GiB used: 17.44 GiB (59.4%) fs: ext4 dev: /dev/sda3
  ID-2: /boot/efi size: 2 GiB used: 33.2 MiB (1.6%) fs: vfat dev: /dev/sda1
  ID-3: /home size: 14.67 GiB used: 10.26 GiB (69.9%) fs: ext4
    dev: /dev/sda9
Swap:
  ID-1: swap-1 type: partition size: 11 GiB used: 0 KiB (0.0%) dev: /dev/sda13
Sensors:
  System Temperatures: cpu: 30.0 C mobo: 30.0 C
  Fan Speeds (rpm): fan-1: 0 fan-2: 1217 fan-3: 0 fan-4: 0 fan-5: 0 fan-7: 0
  Power: 12v: N/A 5v: N/A 3.3v: 3.39 vbat: 3.20
Info:
  Memory: total: 16 GiB available: 15.47 GiB used: 3.48 GiB (22.5%)
  Processes: 281 Uptime: 1d 14h 49m Init: systemd
  Packages: 1299 Compilers: gcc: 14.1.1 Shell: Bash v: 5.2.26 inxi: 3.3.34

Mas KInfoCentre, Conky, inxi, não atendem a vasta comunidade dos adeptos do ricing em todos os níveis — dos iniciantes aos veteranos.

Exemplos de alternativas ao Neofetch sugeridas na internet

Vários blogs listaram algumas alternativas ao Neofetch. — Mas existem dezenas de “fetch”, para todos os casos, perfis, gostos e preferências, dos mais simples aos mais completos. — Como escolher?

Alguns critérios objetivos podem ajudá-lo:

Precisão das informações exibidas — a começar pela Memória RAM usada por sua distro + DE / WM — pois não faz sentido, cada um utilizar um cálculo diferente, como se fosse questão de “gosto pessoal”.

Ver “Minha distro é mais leve do que a sua!”, no final.

Facilidade de adicionar e remover itens — pois não adianta agradar em quase tudo — e omitir 1 item que o usuário gostaria de mostrar — ou exibir 1 item que o usuário prefere não expor.

Possibilidade e facilidade de configurar a aparência — afinal, cada um deseja ser diferente.

Caracterização. — Muitos querem exibir a logo de sua distro — e não um pinguim genérico, por exemplo.

Manutenção ativa e constante. — Isso é fácil de avaliar, quando um projeto já tem 1 ou 2 anos — mas é uma incógnita, se foi lançado na semana passada (mesmo que, em poucos dias, tenha lançado sua enésima versão).

Disponibilidade no maior número de repositórios. — Indica aceitação por grande número de usuários e mantenedores de distros — e observação permanente do código por inúmeras pessoas (pois ninguém pode examinar tudo sozinho).

Rapidez de execução. — Isso pode ser importante, para quem configura a execução automática, ao abrir o emulador de Terminal. — Eu não faria isso, pois a abertura de um Terminal já altera o uso de Memória RAM da distro + DE / WM.

Ver “Minha distro é mais leve do que a sua!”, no final.

Fastfetch: de 2.430 “estrelas” no Github, em 1º Maio 2024, para 7.427 em 12 Junho

Um passeio pelos fóruns, grupos, comunidades etc. mostrou que o Fastfetch foi, de longe, o mais indicado e bem aceito pelos usuários: — Ele é rápido como um raio (25 a 40 vezes mais que o Neofetch), recebe atualizações frequentes, e traz 20 configurações facilmente combináveis para personalizar do jeito que se quiser. — Praticamente liquidou o debate, em poucos dias.

Mas ainda podemos preferir outro.

Índice

Alternativas nos repositórios
Os “fetch” mais rápidos
O cálculo do uso de RAM
Cálculo correto

Fastfetch
Neowofetch
hyfetch
pfetch-rs
treefetch
Archey4
Archey3
screenFetch

Cálculo errado

Nerdfetch
Paleofetch
pfetch

Cálculo muito errado

Macchina
RuFetch

Sem cálculo

afetch
ramfetch
ufetch

Arquivados

Neofetch
UwUfetch

Descartados

cpufetch
hwinfo
speccy
rtfetch
onefetch

“Minha distro é mais leve do que a sua!”
Monitorando pelo Conky
Referências

Alternativas nos repositórios

Pacotes “fetch” disponíveis em 3+ “famílias” de repositórios

Uma busca por “fetch”, no Repology, em 12 Junho 2024, listou 14 nomes em 3 ou mais “famílias” de repositórios (exemplo: Debian + derivados = 1 “família”). — Adicionei Macchina e Archey4 (que não têm “fetch” no nome), e a lista aumentou para 16.

Ocultei na planilha os projetos que buscam (“fetch”) emails, músicas, vídeos, certificados, Github (onefetch) etc., fora do escopo aqui.

O Neofetch, o UwUfetch e o pfetch foram arquivados por seus desenvolvedores. — Outro desenvolvedor retomou o pfetch — mas qualquer dessas 2 versões será desinstalada caso você instale o pfetch-rs.

Isso tem mudado muito. — Em 5 Maio tive de instalar o Fastfetch do AUR — e 2 dias depois, ele apareceu no repositório oficial do Arch. — Em 12 Junho, já estava também no repositório do Void Linux.

Vários desenvolvedores trataram de lançar novas versões (com ou sem grandes mudanças), logo após o arquivamento do Neofetch — mas é comum os repositórios das distros demorarem a incorporá-las.

As datas (acima) são do Git de cada um. — “Spr” (spread) indica o número de “famílias” de repositórios. — Entre parêntesis, quantas “famílias” oferecem a versão mais recente.

Embora o Fastfetch estivesse em 23 “famílias” de repositórios, apenas 15 tinham a última versão.

Em Novembro, o Fastfetch já estava em 30 “famílias” de repositórios — 23 com a versão mais recente.

Pacotes “tipo fetch” mais populares no AUR

Quando um pacote está em apenas 2 “famílias” de repositórios, muitas vezes, são o AUR (86.000+ pacotes) e o NixPKG (100.000+ pacotes). — Centrei meus testes no Arch Linux + AUR, por comodidade.

Para filtrar o excesso, no AUR, pesquisei “fetch” e classifiquei, em 1º lugar, por “Popularidade” (ordem decrescente) — e em 2º lugar, por atualização no AUR (idem).

Apareceu Macchina — porque o AUR procurou “fetch” também na descrição — mas não o Archey, que adicionei depois na planilha.

Ocultei na planilha os projetos que buscam (fetch) emails, músicas, vídeos, certificados, Github etc.

O AUR faz uma “ponderação” dos votos, considerando os dias desde a criação do pacote — o que dinamiza as avaliações — mas convém ter cuidado com explosões momentâneas de “popularidade”.

Stormfetch, o mais popular do momento, apareceu no GitLab em 4 Maio 2024 (v.1.0); em apenas 12 dias chegou à v.3.0 (a última no AUR); e no mesmo dia, já lançou a v.3.1. — Ele é tão novo, que cada voto vale muito. — Em meados de Maio, davam-lhe 1,99 de popularidade. Em Novembro, apenas 0,07 de popularidade.

Já o Nerdfetch (100% Shell), está no AUR desde Out. 2020 (embora no Github e no Codeberg só constem as versões 5.0, de Fev. 2022, em diante). — Em meados de Maio, tinha zero votos e popularidade 0,0. — Em 1º Junho, tinha 7 votos e popularidade 0,87. Ganhou novos fãs.

Distros que já ofereciam Fastfetch, em Outubro 2024, segundo o PKGs

Para descobrir os “fetch” disponíveis nos repositórios de cada distro, recorri ao PKGs. — Isso facilitou me concentrar nas distros que ofereciam maior número e variedade de pacotes "fetch”.

Mas não cheguei a instalar todos esses “fetch”. — O que testei foi um mix de apenas alguns entre eles, considerando:

Os mais citados nos portais, blogs, fóruns etc.

Os que estão no maior número de “famílias” de repositórios

Os mais “populares”, segundo o AUR

Os que encontrei nos repositórios de minhas distros.

Eu já tinha o Neofetch e o screenFetch em todas as minhas 12 distros, por serem os mais comuns até então. — Agora, estou trocando ambos pelo Fastfetch, nas distros que já o oferecem.

Os “fetch” mais rápidos

Tempo de execução dos “fetch” (3 amostras); e linguagens utilizadas

Para registrar o uso de Memória RAM (e monitorar a mudança desse cálculo), costumo executar comandos com grep (no Conky, e em bash scripts). — Foi isso que usei para verificar os tempos de execução:

sleep 2m; time archey3 | grep RAM
sleep 2m; time archey4 | grep RAM
sleep 2m; time fastfetch | grep -o -P '.{0,0}Memory.{0,30}'
sleep 2m; time hyfetch | grep Memory
sleep 2m; time macchina | grep -o -P '.{0,0}Memory.{0,50}'
sleep 2m; time neofetch | grep 'RAM\|Memory'
sleep 2m; time neowofetch | grep 'RAM\|Memory'
sleep 2m; time paleofetch --stdout  | grep 'RAM\|Memory'
sleep 2m; time pfetch | grep -o -P '.{0,0}memory.{0,30}'
sleep 2m; time rufetch | grep Memory
sleep 2m; time screenfetch | grep 'RAM\|Memory'
sleep 2m; time treefetch | grep memory
sleep 2m; time uwufetch | grep -o -P '.{0,0}MEMOWY.{0,30}'
sleep 2m; time afetch | grep OS
sleep 2m; time ramfetch | grep Dirty

Executei os comandos 3 vezes, no Arch, em intervalos de 2 minutos, para que uns não afetassem os outros — e ordenei os resultados pelas médias, do mais rápido para o mais demorado. — As linguagens utilizadas (e seus percentuais) são indicações do Github.

Os tempos do Archey4 mudaram drasticamente, de 1.400 ms nos primeiros dias, para cerca de 12.000 ms, dias depois — e quando retirei “WAN IP” caíram para 200 ms.

O pfetch também variou de 43 a 51 ms, nos primeiros dias, para 67 a 110 ms, alguns dias depois. — Ele foi removido pela instalação do pfetch-rs (Rust: 8 ms), cujo binário tem o mesmo nome e responde ao mesmo comando, e por isso não são compatíveis.

O hyfetch usa o Neowofetch, com aumento de 200 a 400 ms em seu tempo de execução (que já é alto) — mas pode usar o Fastfetch (se instalado), com tempo de execução de pouco mais de 200 ms.

O Neofetch e o UwUfetch foram arquivados por seus desenvolvedores.

Fica claro um dos motivos por que o Fastfetch tem alcançado preferência tão imediata, logo que a discussão se espalhou: — Ele é executado em 13 ms — enquanto o Neofetch demora 500 ms (no Arch Linux).

Os “fetch” escritos em Rust e C tendem a ser mais rápidos. — Porém, dentro de cada linguagem, a demora é proporcional à quantidade e complexidade das informações exibidas. — Itens mais “básicos” exigem bem menos tempo, mesmo em Shell.

Além disso, os tempos de execução variam de uma distro para outra:

Tempo de execução dos vários “fetch” no Debian Testing

Nos repositórios oficiais do Debian Testing, encontrei o Neowofetch e o hyfetch, como pacotes autônomos. — Pode-se instalar só o Neowofetch — mas não se pode instalar o hyfetch sozinho.

Em Julho, encontrei o Fastfetch nos repositórios do Debian Testing (e do Ubuntu 24.10, entre outros). — Ao instalar no Debian, ele executou em 14 ms. — Copiei a pasta de configurações, da /home do Arch para a do Debian, e executou em 811 ms. — Após alguns ajustes, tem executado em 431 ~ 451 ms (4 testes até Outubro 2024).

Tempo de execução dos “fetch” no Fedora 40

No repositório oficial + RPM Fusion do Fedora 40, encontrei o Fastfetch e o hyfetch (que traz junto o Neowofetch) — além do afetch, que não indica o uso de Memória RAM.

Me surpreendeu ver o Neofetch demorar praticamente o mesmo que o Neowofetch — e o screenFetch, mais ainda.

Tempo de execução dos “fetch”no openSUSE Tumbleweed

Nos repositório oficial + Pakman Essentials do openSUSE Tumbleweed encontrei o Fastfetch, o treefetch e o Macchina — além de 3 versões python31x-hyfetch (310, 311, 312). — Instalei python311-hyfetch, que trouxe o Neowofetch.

Tempo de execução dos vários “fetch” no Void Linux

No repositório oficial do Void + templates “void-packages”, encontrei velhas versões do ufetch e do pfetch. — O ufetch não indica o uso de RAM — e o pfetch utiliza o “cálculo antigo”.

No final de Maio 2024, apareceu o Fastfetch.

Tempo de execução dos vários “fetch” no Redcore Linux

No repositório do Redcore encontrei o screenFetch — e nos ebuild's do Gentoo, o Neofetch, o Fastfetch e o hyfetch (que traz o Neowofetch). — Todos executaram mais rápido do que nas outras distros, e com menores variações ao longo de 4 testes.

O cálculo do uso de RAM

Diferentes cálculos do uso de Memória RAM pelos “fetch” que testei

Das 17 ferramentas “fetch” que testei no Arch Linux até agora, 5 ainda mantêm o “cálculo antigo” do uso de Memória RAM — e 2 utilizam o que apelidei de “cálculo muito antigo”. — Não recomendo, pois dão apenas uma falsa impressão de que “minha distro + DE / WM é muito leve”.

Outras 2 ferramentas não indicam o uso de Memória RAM — inclusive ramfetch, o que parece incoerente com seu nome.

Ficam 8 ferramentas — mas, entre elas, não recomendo screenFetch, que não é atualizado ha mais de 4 anos — e por outros motivos que ficarão claros mais adiante.

MEM_TOTAL=$(awk '/MemTotal/ { printf $2 }' /proc/meminfo);\
MEM_AVAIL=$(awk '/MemAvailable/ { printf $2 }' /proc/meminfo);\
MEM_USED_KILO="$(($MEM_TOTAL-$MEM_AVAIL))";\
echo "$(($MEM_USED_KILO/1024))" MiB \(MemInfo T-A\)    >> RAM_02-Arch_____
treefetch | grep memory                                >> RAM_02-Arch_____
macchina | grep -o -P '.{0,0}Memory.{0,50}'            >> RAM_02-Arch_____
paleofetch --stdout  | grep 'RAM\|Memory'              >> RAM_02-Arch_____
fastfetch | grep -o -P '.{0,0}Memory.{0,30}'           >> RAM_02-Arch_____
uwufetch | grep -o -P '.{0,0}MEMOWY.{0,30}'            >> RAM_02-Arch_____
pfetch | grep -o -P '.{0,0}memory.{0,30}'              >> RAM_02-Arch_____
archey3 | grep -o -P '.{0,0}RAM.{0,30}'                >> RAM_02-Arch_____
rufetch | grep Memory                                  >> RAM_02-Arch_____
neofetch  --stdout | grep "Memory"                     >> RAM_02-Arch_____
screenfetch -n -N -E | grep "RAM"                      >> RAM_02-Arch_____
neowofetch --stdout  | grep 'RAM\|Memory'              >> RAM_02-Arch_____
archey4 | grep -o -P '.{0,0}RAM.{0,30}'                >> RAM_02-Arch_____
hyfetch | grep -o -P '.{0,0}Memory.{0,30}'             >> RAM_02-Arch_____

Esses números do uso de Memória RAM foram obtidos por um script (agendado para 5 minutos uptime), que realiza o “cálculo novo” com dados do /proc/meminfo — e o registra em um arquivo TXT, junto com os números indicados pelas ferramentas “fetch”. — Reiniciei a máquina, carreguei o Arch e deixei ocioso (idle), até o script salvar esses dados.

Isso evita abrir um emulador de Terminal — o que alteraria o uso de RAM.

Ordenei a lista pelo tempo de execução (médias até 20 Maio). — As versões são as que eu tinha no Arch, no dia 20 Maio. — Os dados do pfetch-rs e do Nerdfetch, assim como as datas da última atualização (Git), são acréscimos posteriores.

Cálculo correto

Fastfetch

Aspecto inicial do Fastfetch e configurações alternativas oferecidas prontas

Entre as ferramentas mais rápidas, o Fastfetch (escrito em C) bate todos os outros em quantidade de informações, em número de configurações já prontas (presets & examples), e em facilidade de personalização.

O Fastfetch utiliza o “cálculo novo” do uso de Memória RAM; e seu desenvolvimento está a pleno vapor. — No Github, publicou nada menos que 100 versões em 2 anos — 12 das quais, entre 30 Abril e 7 Junho 2024.

Ao executar o Fastfetch pela primeira vez, até me assustei com mais de 50 linhas de informações sobre o sistema — incluindo IP local, resolução da tela, temas global e de decoração de janelas, ícones, fontes, cursor, regionalização, terminal — e todas as minhas 28 partições, indicadas como “discos”.

O desenvolvedor tranquiliza os que receiam expor seu IP local:

Um IP local não tem nada a ver com privacidade. Só faz sentido se você estiver na mesma rede, por exemplo, conectado à mesma rede Wi-Fi.
O módulo Local IP é o mais útil para mim pessoalmente. Tenho várias VMs para testar o Fastfetch e muitas vezes preciso fazer SSH nelas. Tenho o Fastfetch em execução na inicialização do shell e nunca preciso digitar ip addr manualmente.
Se você realmente não gostar, pode desabilitar o módulo Local IP no config.jsonc.

Basta um parâmetro “-c” para imitar o layout do Paleofetch, do Neofetch, do Archey — ou “software”, “btw”, “hardware” (cada um com um tempo diferente de execução) — ou “all”, que exibe todas as informações (demorou 2 min 14s, aqui) — ou “ci”, que esmiúça as entranhas do PC, em umas 150 linhas (com o tempo parcial de cada item, e um tempo total de 1.038 ms) — afora “exemplos” numerados de 2 a 13:

$ fastfetch -c software.jsonc
$ fastfetch -c paleofetch.jsonc
$ fastfetch -c neofetch.jsonc

$ fastfetch --list-presets
software.jsonc
paleofetch.jsonc
neofetch.jsonc
archey.jsonc
btw.jsonc
hardware.jsonc
all.jsonc
examples/
  | 13.jsonc
  | 12.jsonc
  | 4.jsonc
  | 9.jsonc
  | 3.jsonc
  | 8.jsonc
  | 5.jsonc
  | 10.jsonc
  | 7.jsonc
  | 6.jsonc
  | 11.jsonc
  | 2.jsonc
ci.jsonc

$ fastfetch --load-config /usr/share/fastfetch/presets/examples/2.jsonc
$ fastfetch --load-config /usr/share/fastfetch/presets/examples/3.jsonc
...
$ fastfetch --load-config /usr/share/fastfetch/presets/examples/13.jsonc

Fui combinando seus vários parâmetros — exibir só 3 partições, trocar o verde pelo amarelo — e no final adicionei o parâmetro “--gen-config” para gerar meu arquivo pessoal ~/.config/fastfetch/config.jsonc:

$ fastfetch --disk-folders /
$ fastfetch --disk-folders /:/home
$ fastfetch --disk-folders /:/home:/run/media/flavio/Warehouse

$ fastfetch --color yellow

$ fastfetch --disk-folders /:/home:/run/media/flavio/Warehouse --color yellow
$ fastfetch --disk-folders /:/home:/run/media/flavio/Warehouse --color yellow --gen-config-force

Editando meu arquivo de configuração pessoal do Fastfetch

Depois, ainda editei meu arquivo pessoal de configuração, para retirar várias coisas que achei supérfluas — como ícones, fontes, cursor, fontes do Terminal, IP local, bateria (PC desktop), adaptador de energia etc.

Configuração pessoal (provisória) do Fastfetch

Isso tudo foi só um exercício, pois é improvável que eu use qualquer “fetch” para me informar dessas coisas. — O uso das 28 partições, por exemplo, o Conky me mostra em gráficos bem mais legíveis (embaixo, à esquerda, na tela).

Para voltar a exibir o Fastfetch “padrão”, bastou renomear o arquivo de configuração pessoal para “x_config.jsonc”, por exemplo, para ser ignorado.

O “--help” (235 linhas) e o manual (98 linhas) dizem tudo que precisei saber, para fazer essa configuração provisória — e o Github do Fastfetch tem mais informações que poderão ser úteis.

Neowofetch

Neowofetch, em sua configuração padrão

Neowofetch se propõe a ser “o próprio Neofetch” — atualizado, corrigido, com novos recursos pedidos pelos usuários — e utiliza o “cálculo novo” do uso de RAM.

É mantido com o hyfetch — em 1 só Github — para que ele não dependa mais do Neofetch “original”.

O comando neowofetch é uma opção para quem quer um Neofetch atualizado, sem as bandeiras de orgulho LGBTQ+ — e o nome diferente é para evitar conflitos entre os comandos, binários etc. — Portanto, sua instalação não exige remover o Neofetch.

No Debian Testing, o Neowofetch pode ser instalado sozinho — embora seja dependência indispensável ao hyfetch — mas o Repology não “vê” Neowofetch no Debian, nem em qualquer outra distro (só uma versão muito antiga, no AUR). Não “existe” de modo independente.

No openSUSE, no Arch Linux (e Manjaro), no Fedora, no Redcore / Gentoo (e outras distros que não tenho), a única maneira de obter o Neowofetch é instalar o hyfetch.

Com essa convivência de 2 projetos em 1 Github, a proporção de códigos “Shell (55.1%); Python (44.7%)” talvez signifique que o hyfetch seja feito em Python — uma vez que o Neofetch “original” usa “Shell (96.7%)”. — O uso de 1 só Github também prejudica o conceito de “atualização”, pois indica que a última versão (do hyfetch) é de Dezembro 2023, embora Neowofetch tenha recebido várias atualizações, depois disso.

O “--help” do Neowofetch tem 287 linhas — é muito semelhante ao do Neofetch (274 linhas) — e manda relatar bugs no Github... do Neofetch!

Além disso, identifica-se (pelo parâmetro “--version”) como “Neofetch 7.3.11” — enquanto o Neofetch “original” parou na versão 7.1.0.

A página do hyfetch no Github mantém o Readme do Neofetch — ou melhor, do Neowofetch! — logo após o seu, na página inicial.

A situação pode ser resumida assim, no Arch Linux — mas também em outras distros, com os devidos ajustes:

$ whereis hyfetch
hyfetch: /usr/bin/hyfetch

$ whereis neowofetch
neowofetch: /usr/bin/neowofetch

$ pacman -Ss hyfetch
extra/hyfetch 1.4.11-2 [installed]
    Neofetch with LGBTQ+ pride flags!

$ pacman -Ss neowofetch
    (nothing!)

$ neowofetch --version
Neofetch 7.3.11

$ hyfetch --version
Version is 1.4.11

Nenhum dos 2 instalou um manual — no Arch Linux, no openSUSE Tumbleweed ou no Fedora 40 etc. — mas não fez falta.

Ambos demoram um pouco mais do que o Neofetch — exceto no Redcore — e muito mais que o Fastfetch.

hyfetch

hyfetch no Arch Linux

O hyfetch é “um Neofetch com bandeiras de orgulho LGBTQ+” — na logo, do lado esquerdo — e exibe o uso de RAM pelo “cálculo novo”.

Na verdade, executa o Neowofetch — que é quem busca (fetch) as informações e as apresenta do lado direito.

Configuração inicial (padrão) do hyfetch / Neowofetch no Debian e no Arch

Ao executar o hyfetch pela primeira vez, ele detectou o “color mode” (RGB) e o “background color” (Dark) do sistema. — Passou direto ao item 3, onde o usuário pode escolher entre 54 “flags” (padrão: Rainbow); — no item 4, escolher o brilho, entre 50% e 80% (padrão: 65%); — e no item 5, o alinhamento das cores, entre horizontal (padrão), vertical e várias opções randômicas.

O ovo de páscoa do mês do orgulho, by hyfetch

Em Junho, costuma exibir, primeiro, um festival de cores — o ovo de páscoa do mês do orgulho — e só após teclar Enter, mostra a logo da distro e as informações do sistema. — Pode-se obter o mesmo efeito pelo parâmetro “--june”.

O “--help” do hyfetch tem apenas 41 linhas. — O parâmetro “-c” refaz todos os passos do processo de configuração — e isso diz respeito apenas às cores do logo ASCII da distro (lado esquerdo).

Para configurar o bloco de informações sobre o sistema (lado direito), deve-se configurar o Neowofetch — que é o “motor” por trás do hyfetch.

hyfetch usando o Fastfetch: — Bem mais rápido

Pelo comando hyfetch -b fastfetch, pode-se optar pelo Fastfetch — se estiver instalado — como “motor” do hyfetch.

Tempos de execução do hyfetch, usando o Neowofetch ou o Fastfetch

Além de adicionar as cores, o hyfetch aumenta em cerca de 200 a 400 ms o tempo de execução do Neowofetch (que já é demorado) — ou em cerca de 200 ms o tempo do Fastfetch (o que ainda é bem rápido).

Lembrar que o tempo de execução do Fastfetch pode variar bastante, conforme a configuração utilizada.

 --backend {qwqfetch,neofetch,fastfetch,fastfetch-old}
        -b {qwqfetch,neofetch,fastfetch,fastfetch-old}

Além do Fastfetch, o hyfetch pode usar o Neofetch “original” (defasado) — ou o qwqfetch (Python 100%), ainda em desenvolvimento. — Não encontrei em nenhum lugar, para instalar e fazer a experiência.

pfetch-rs

pfetch-rs 2.9.2 do AUR, no Arch Linux

O pfetch-rs é simples e rápido — cerca de 10 vezes mais que o original — e já adotou o “cálculo novo” do uso de Memória RAM.

Foi lançado em Fevereiro 2023, e desde então apresentou 16 versões. — A última (2.9.2), de 3 Junho 2024, já está no AUR, NixPKGs, Alpine, Homebrew.

Segundo o Github, é escrito em Rust (60.5%); Shell (39.0%); Typst (0.5%). — Também tem uma página no Crates — ambas úteis para configurar.

Sua instalação implica em remover o pfetch — pois seu binário tem o mesmo nome, e responde ao mesmo comando — o que os torna incompatíveis.

treefetch

Aparência e possibilidades do treefetch, no Arch Linux

O treefetch é escrito em Rust, e é muito rápido. — Além disso, é bem simples, e seu Help ainda mais simples: — Pode-se escolher entre a árvore padrão, um bonsai, ou uma árvore de Natal.

Utiliza o “cálculo novo” do uso de Memória RAM

A versão 1.0 foi lançada no Github em Dezembro 2021 — e teve 4 atualizações em 1 mês, até a versão 2.0, em Janeiro 2022

Está em 4 famílias de repositórios: AUR, Gentoo, LiGurOS, openSUSE

Archey4

Archey4 utiliza o “cálculo novo” do uso de Memória RAM — mas no começo não me causou grande impressão, com suas 20 informações — e um tempo de execução um tanto demorado, em torno de 1.400 ms nos primeiros dias (19 a 24 Maio).

Algumas informações eram vazias (como “Model”, que meu PC desktop caseiro não tem) — ou sem interesse em exibir (como “LAN IP” e “WAN IP”) — e não senti interesse nos poucos recursos de seu “--help” ou de seu manual, ambos fraquíssimos.

Retirada da linha “WAN IP”, nas configurações do Archey4

O que chamou atenção foi que, a partir da noite de 25, passou a demorar 12.000 ms — e não encontrei qualquer registro de ter mexido nas configurações da Bios ou do Arch — que só atualizei dia 26 (Domingo).

No dia 27, ainda apresentava tempos de execução de 12.000 ms. — Na Terça-feira, 28, retirei “WAN IP” — e passou a executar em 200 ms.

Recorri ao seu Github, cuja página inicial oferece tudo que falta em seu “--help” e em seu manual: — Criar a pasta ~/.config/archey4, copiar para ela o arquivo /etc/archey4/config.json — e editar à vontade, com base na versão comentada e explicada, do site.

Tudo isso estava em /usr/share/archey4/README.md (em markdown), mas só descobri depois.

Ao examinar “WAN IP”, vi chamadas para 3 sites. — O ping levou 5.000 ms para concluir que não há endereço associado ao primeiro — e 6 ms para concluir que o terceiro é desconhecido.

O Github do Archey4 indica 39 versões desde a inicial (4.0.0), em Maio 2017 — com uma lacuna em todo o ano de 2019 — e outra lacuna de 8 meses entre Agosto 2023 e a versão atual (4.14.3.0), de 6 Abril 2024.

O antigo Archey (100% em Python) existia desde Dez. 2009, segundo a data de sua descrição. — Em Agosto 2014, Melik Manukyan dizia estar pensando em reescrever o código por completo, mas isso nunca aconteceu. — Em 2017, Samuel Forestier retomou o desenvolvimento, criando o Archey4.

Archey3

Aspecto e possibilidades do Archey3

O Archey3 mostra as informações básicas do sistema — e o parâmetro “-s” faz a captura da tela (usando o ImageMagick). — Também já utiliza o “cálculo novo” do uso de Memória RAM.

Editei o arquivo de configuração ~/.archey3.cfg (no alto, à direita) — retirei o item “env(editor)” (que aparece no original em azul, à direita, centro) — e usei o parâmetro “-c yellow” para torná-lo mais legível, pois as letras em verde ou azul são menos nítidas sobre o fundo preto.

A página do projeto é útil — em especial as páginas “more examples” e “config reference” — mas só no seu Github encontrei a data da versão 0.4 (2011). — Ainda não descobri a data da versão atual (0.5).

Também é fork do antigo Archey (e já vi um Archey2 em algum lugar).

screenFetch

O screenFetch é uma das mais antigas ferramentas “fetch” — data de 2010 — e já faz alguns anos que adotou o “cálculo novo” do uso de Memória RAM.

A versão 3.9.0 (Out. 2019) dizia trazer inúmeras novidades, porém não citou nenhuma. — Kitty Katt alegava não ter participado das mudanças, e por isso nem saberia listá-las. — Foi talvez ali, que adotou o “cálculo novo” do uso de RAM?

Kitty Katt falava de uma versão 4, de uma reescrita completa do código etc., como vagas possibilidades — mas parou na versão 3.9.1, de Nov. 2019.

$ screenfetch -s
$ screenfetch -s "gnome-screenshot -p -f ~/$(date +%F_%H-%M-%S)_Xxx.jpg"
$ screenfetch -s spectacle -p -b -o ~/$(date +%F_%H-%M-%S)_Xxx.jpg

Seu “--help” de 80 linhas e seu manual de 130 linhas esclarecem os recursos oferecidos. — O parâmetro “-s”, por exemplo, permite capturar a tela pelo scrot (ou pelo gnome-screenshot, Spectacle) — e o parâmetro “-u” se propõe fazer o upload da captura para um site que esteja pré-configurado (não testei).

Um dos itens mais interessantes, na vasta Wiki do seu “concorrente” Neofetch, é o histórico “Neofetch vs. screenFetch”, onde explica “Por que o Neofetch foi criado” — “O problema com o screenFetch” — e “Como o Neofetch difere do screenFetch”.

Ali, o desenvolvedor do Neofetch expôs toneladas de inadequações no código do screenFetch — e talvez tenha sido uma das causas do ostracismo a que o screenFetch foi relegado, desde então.

Cálculo errado

Nerdfetch

Opções de “fontes nerd” no Nerdfetch

Embora nerdfonts sejam a característica marcante do Nerdfetch, não são dependências obrigatórias para sua instalação. — Apenas, sem alguma fonte nerd, as linhas serão encabeçadas por retângulos anódinos. — Limitei-me a instalar ttf-cousine-nerd (entre 70+ fontes otf e ttf encontradas pelo pacman), e obtive os resultados acima.

Infelizmente, utiliza o cálculo antigo de uso de Memória RAM.

O Nerdfetch (100% Shell) está em 4 “famílias de repositórios”. — Está no AUR desde Out. 2020 — embora no Github e no Codeberg só conste da versão 5.0 (Fev. 2022) em diante.

Paleofetch

Aparência e possibilidades do Paleofetch

O Paleofetch, escrito em C, está entre os mais rápidos — e não tem “--help” ou manual.

Para configurar, deve-se editar o arquivo “config.h” e recompilar — não me pergunte como.

Ainda utiliza o “cálculo antigo” do uso de Memória RAM

A versão 0.1.0 entrou no Github em Abril 2020 — e lançou mais 2 versões em 24 horas

Está somente no AUR — onde entrou em Abril 2020, e atualizou até Julho 2020

pfetch

pfetch, no Arch Linux

Embora Repology aponte o pfetch em 15 “famílias de repositórios”, em 11 desses casos trata-se da versão 0.6.0, de Março 2020 — do mesmo desenvolvedor do Neofetch, que também o arquivou em 26 Abril 2024.

Apenas no AUR, encontrei a versão 1.0.1 de um fork lançado em Maio 2024 — e que foi atualizado para 1.1.0 em Junho 2024. — Infelizmente, esse fork manteve o “cálculo antigo” do uso de Memória RAM.

Foi substituído quando instalei o pfetch-rs — cujo binário tem o mesmo nome e responde ao mesmo comando, sendo portanto incompatíveis.

Cálculo muito errado

Macchina (bin)

Aparência e possibilidades do Macchina

Segundo seu desenvolvedor, Macchina está “em modo manutenção” — com prioridade para correção de bugs e melhorias de performance — mas não publica há mais de 1 ano.

A instalação do “macchina” falhou no Arch Linux (pelo yay), então instalei “macchina-bin”.

Utiliza o “cálculo muito antigo” do uso de RAM, já abandonado por todas as ferramentas mais conhecidas

Lançou a versão 0.3.1 no Github em Fevereiro 2021 e mais 62 versões até a 6.1.8, em Janeiro 2023

Está em 10 famílias de repositórios — incluindo AUR, Gentoo, NixPKGs, openSUSE

RuFetch

Configuração do RuFetch

O RuFetch exibiu uma longa tripa com todos os “discos” (partições) e temperaturas possíveis e imagináveis. — Nenhuma logo em ASCII para enfeitar a tela.

Ele é escrito em Rust e, para configurá-lo, o usuário deve criar a pasta + arquivo ~/.config/ru_fetch/config.toml — o que me custou meia-hora no Google para descobrir a sintaxe correta: — dois pontos? sinal de igualdade? espaços? — Funcionou com “igual” entre espaços.

Infelizmente, ainda utiliza o “cálculo muito antigo” do uso de RAM — e para piorar, só permite escolher entre unidades SI (KB, MB, GB) — o que dificulta comparar com os números em KiB, MiB, GiB das demais ferramentas.

Caso não goste do seu uptime em horas com frações decimais, poderá optar por vê-lo em minutos ou segundos (e fazer a conta “de cabeça”). — Afora isso, ele é bastante configurável, e você pode aprender mais no seu Github — onde constam 8 versões de Fev. a Dez. 2021. — A de Março foi colocada no AUR em Maio 2021 (e ficou nisso).

Sem cálculo

afetch

afetch, no Fedora

O afetch se propõe ser simples e rápido, e de fato é um dos mais simples que encontrei até agora: — não indica sequer o uso de Memória RAM — mas perde em velocidade para o treefetch, e até para o Fastfetch cheio de recursos.

Não encontrei Help nem Manual. — Seu Github sugere editar um arquivo “config.h” — mas não consegui entender onde, nem como, nem o que fazer depois. — Tive a impressão de que as possibilidades são de configurar um separador nas linhas, forçar ou não letras maiúsculas, e alterar a cor do texto.

Na página do projeto no Github, constam 5 versões. — As versões 1 e 2.0 foram lançadas em um único dia, em 2021 — e as versões 2.0.1 e 2.1.0, nas 48 horas seguintes. — A versão atual 2.2.0 foi lançada 3 meses depois, ainda em 2021.

ramfetch

Os números do ramfetch — e (quase) a mesma seleção no /proc/meminfo

O ramfetch exibe algumas informações da Memória RAM, extraídas do arquivo de sistema /proc/meminfo. — Seleciona alguns números, muda alguns nomes, coloca em outra ordem — e converte os números de “kB” (SI) para uma salada de B, KiB, MiB, GiB e TiB (grudados nos números, cujas colunas ficam desalinhadas, o que dificulta ainda mais a leitura).

Mas não faz a conta: — Mem used = MemTotal - MemAvailable. — Ou seja, não indica a Memória RAM usada.

A página do projeto está no Codeberg, sem muita informação. — Foi lançado em Dezembro 2022 e publicou 8 versões até Abril 2023.

ufetch

ufetch, que só encontrei no repositório do Void Linux

Só encontrei o ufetch no Void Linux. — É tão simples quanto o pfetch, e o tempo de execução deles é muito parecido. — A diferença é que ufetch não indica o uso da Memória RAM. — A versão 0.3 não tem “--help”.

Mudou-se, em 2020, do Github para o GitLab, onde a versão 0.1 é de Março 2019 e a versão 0.3 é de Dezembro 2022.

Arquivados

Neofetch

R.I.P. Neofetch

O arquivamento do Neofetch no Github, por seu desenvolvedor, não quer dizer que vá parar de funcionar na máquina do usuário, nem que foi banido dos repositórios (por enquanto). — Apenas, não vai mais receber correção de bugs, nem atender pedidos de melhorias — como, aliás, já não fazia, há 3 ou 4 anos.

Seu desenvolvimento prossegue no Neowofetch

Seu lançamento inicial (versão 0.1) foi em 30 Dez. 2015 (Github em Jan. 2016). — A última versão (7.1.0) é de Ago. 2020 — e a última alteração, de Dez. 2021.

UwUfetch

UwUfetch, no Arch Linux

UwuFetch foi lançado em Março 2021 e recebeu 9 atualizações ao longo de 2 anos, até Fevereiro 2023, embora registre atividade constante, mês a mês, até Abril 2024 — quando foi arquivado no Github, por seu desenvolvedor, para se dedicar à conclusão do curso universitário. — Ele diz que não pretende mais se dedicar ao projeto, mas que talvez mude de ideia. Quem sabe?

Infelizmente, utiliza o “cálculo antigo” do uso de RAM.

UwUfetch oferece imagens PNG (ainda não baixei), para exibir em lugar das logos em arte ASCII, pelo parâmetro “-i” — desde que se instale a dependência opcional viu — “extra/viu - Simple terminal image viewer”, no Arch (não testei).

O “--help” é pequeno, mas o manual de 126 linhas ensina a configurar, e inclui um dicionário da linguagem “uwu-memética”.

Descartados

cpufetch - Limita-se a informações sobre o modelo da CPU (hardware).

hwinfo - Exibe uma longa lista de informações (17.263 linhas, no meu PC!). — Direcionei a resposta para um arquivo TXT ($ hwinfo > hwinfo.txt), e mesmo assim não é fácil tirar proveito prático. — Com o parâmetro “--short”, obtive 110 linhas, ainda pouco úteis para meu uso diário. — O “--help” oferece outras opções. — Nenhuma semelhança com Neofetch.

speccy - Encontra-se em 6 “famílias” de repositórios — mas não pude acessar sua página. — Usei no Windows, em 2015, minimizado na bandeja do sistema para monitorar a temperatura da CPU, e realmente não era “alternativa” ao Neofetch.

rtfetch - Não encontrei no Repology (nem no AUR, claro).

onefetch - Busca (fetch) informações do Github — e não do sistema.

Ignorei várias outras indicações do site AlternativeTo, abaixo do botão “Show more Neofetch alternatives” — que é um caminho (robótico) sem fim. — O botão sempre torna a aparecer, no final, e a cada vez que se torna a clicar nele, o robô vai adicionando “alternativas às alternativas”, distanciando-se cada vez mais do escopo inicial (mas não deixa de ser uma boa diversão).

“Minha distro é mais leve do que a sua!”

\\\\

Fóruns, grupos, comunidades etc. são um meio prático de trocar informações sobre diferentes distros, Ambientes de Desktop (DEs) e / ou Gerenciadores de Janela (WMs) — mas as comparações podem perder o sentido, se cada participante usar um “fetch” diferente. — Como vimos, alguns medem o uso de Memória RAM pelo “cálculo novo”; outros pelo “cálculo antigo”; e alguns, até, por um “cálculo muito antigo”.

Saber se uma pessoa usou o Neofetch ou o Fastfetch, já poderia dar uma pista sobre o cálculo usado por ela — caso os demais participantes saibam que são diferentes. — Mas quando o “fetch” é executado ao abrir o emulador de Terminal, o nome (comando) não aparece.

Além disso, ao abrir um emulador de Terminal (ou qualquer outro aplicativo GUI), aumentamos o uso de RAM — e esse aumento será maior no caso do Konsole, por exemplo (com muitos recursos), do que com outros emuladores mais leves.

Diferentes “Monitores do Sistema”, como Gnome System Monitor, plasma-systemmonitor, KSysguard etc., também provocam diferentes aumentos do uso de RAM, o que distorce os resultados obtidos por cada participante da conversa, e pode falsear a comparação.

Capturar a tela inteira, sempre é mais informativo, do que capturar apenas o Terminal com o “fetch” — pois os demais participantes poderão ver se não há vários aplicativos GUI abertos.

Há outras coisas que impactam no uso de RAM. — Quando ativada, a suíte “Personal Information Management” (PIM: KMail, Kontact, KOrganizer...) aumenta o uso de recursos do sistema. — Algumas distros instalam e habilitam o PIM; outras permitem escolher KDE Full ou KDE Minimal durante a instalação; e o KDE Neon não instala por padrão.

Permitir que o PackageKit + Plasma Discover comecem a verificar atualizações automaticamente, logo no início da sessão, também vai distorcer o resultado.

O mesmo acontece com a indexação de arquivos pelo Baloo. — Desativei há muitos anos e nunca me fez falta. — E há outros serviços do KDE Plasma que podem ser desativados, caso o usuário não precise deles.

Estes são só alguns exemplos, dentro do KDE Plasma: — Multi-boot de 12 distros Linux — usando o mesmo hardware.

Monitorando pelo Conky

Conky puxando informações de algum “fetch”

Sou tão pouco afeito às ferramentas “fetch”, que só agora percebi que muitos usuários configuram a execução automática de seu “fetch” ao abrir o Terminal. — Eu não faria isso, pois a mera abertura de um emulador de Terminal (GUI) já altera o uso de Memória RAM.

Pessoalmente, prefiro me divertir com o Conky — “feio” , mas com todas as informações de que preciso, para monitorar “o que acontece” — sem abrir um Terminal — e sem afetar o uso de Memória RAM.

Meu Conky puxa várias informações (CPU, iGPU, pacotes instalados) de algum “fetch” — por pura comodidade. — Poderia puxar as mesmas informações com outros comandos, mais “diretos”.

Monitorando as ferramentas “fetch” (entre outras) pelo Conky

Quando o Conky (e outras ferramentas) começaram a mudar o cálculo do uso de Memória RAM — adicionei no Conky meu próprio “cálculo novo” (MemTotal - MemAvailable, vulgo “Total - Available”, ou “T-A”) — encabeçando um bloco com os números indicados por meia-dúzia de ferramentas, para monitorar o avanço dessa mudança (versões diferentes), em várias distros.

Mem:               ${alignr 100}up  ${uptime}

Total - Available  ${alignr 100}${exec bash MemInfo.sh; cat MemInfo.txt}
Conky (Mem)        ${alignr 100}${mem}
free               ${alignr 100}${exec free -m | grep Mem | cut -c 25-35} MiB
top                ${alignr 100}${exec top -E m -b -n 1  | grep buff | cut -c 41-50} MiB
htop               ${alignr 100}${exec export TERM=xterm; echo q | htop | aha --line-fix | html2text | grep -o -P '.{0,6}/15' | cut -b 1-6}iB
inxi               ${alignr 100}${exec inxi --memory-short | grep -o -P '.{0,0}used.{0,14}' | cut -b 6-14}
Fastfetch          ${alignr 100}${exec fastfetch | grep -o -P '.{0,0}Memory.{0,9}' | cut -b 8-12} GiB
# Neofetch           ${alignr 100}${exec neofetch  --stdout | grep -o -P '.{0,0}Memory.{0,9}' | cut -b 8-12} MiB
# screenFetch        ${alignr 100}${exec screenfetch -n -N | grep -o -P '.{0,0}RAM.{0,9}' | cut -b 5-12}

Até o mês passado, eu incluía nesse bloco o Neofetch e o screenFetch. — Agora, estou substituindo ambos pelo Fastfetch — nas distros que já o disponibilizam em seus repositórios oficiais ou “quase-oficiais”.

script (à esq.) para registrar (à dir.) o uso de RAM aos 5 minutos uptime

Para guardar registros detalhados, agendei um script que salva em arquivo TXT os números indicados por todas as ferramentas, 5 minutos após o boot. — Basta ligar o PC, deixar inativo (idle) e ir tomar um café.

___________________
• Publicado em 19 Maio 2024 e desenvolvido até 19 Junho 2024.

— … ≠ “•” ≠ … —

Ferramentas &tc.

O Neofetch parou? Viva o Fastfetch!

Multi-boot de 12 distros Linux

Grub enlouquecido com 12 distros em multiboot

Remanejamento de sistemas Linux ao reparticionar discos

Backup total e limpeza das partições de trabalho
Migrando sistemas Linux para disco rígido de 1 Terabyte
Ensaio de avaliação com luckyBackup e Unison
Particionamento de Drive SSD para vários Linux

Plasma 6.0 em sessão Wayland

noreply@blogger.com (Mboaba) — Tue, 14 Nov 2023 10:33:00 +0000

KDE Neon Unstable com Plasma 6 beta 1, em sessão Wayland

• O KDE Plasma 6.0 em sessão Wayland mostrou-se funcional (para mim), desde a ISO neon-unstable-20231126-1118 do KDE Neon, lançada às vésperas do congelamento do “alpha”. — Depois das primeiras atualizações, tornou-se “beta 1” — e continuou evoluindo (atualizações), até as vésperas do lançamento final.

Encerrei essa experiência em 28 Fev. 2024, quando substituí pela instalação da ISO neon-user-20240228-1346 — já com o Plasma 6 — que resolvi configurar e manter sempre em sessão X11, para comparar.

                     MoBo: TUF B360M-PLUS GAMING/BR - ASUSTeK
                     iGPU: Intel UHD Graphics 630 (Desktop)
                      CPU: 6 × Intel® Core™ i5-9400 CPU @ 2.90 GHz (800 ~ 4100 MHz)
                   Memory: 15.5 GiB RAM

Funcional, mas não confortável. — Uso o KDE Plasma 5 em várias distros, que configuro tão “iguais” quanto possível, para facilitar meu fluxo de trabalho — mas isso está longe de ser possível, no Plasma 6.0 em sessão Wayland.

E nada mais será como antes. — O Plasma 6.0 traz “poucas novidades”, mas vem com uma reorganização profunda — além de eliminar inúmeros pacotes, cujos mantenedores não estão ativos. — Isto implica na perda de muitos recursos (até que novos desenvolvedores retomem os pacotes abandonados).

Muitos de nós já passamos por isso — pelo menos, os que viveram a passagem do KDE4 para o KDE5 — e é por isso que achei prudente me antecipar, “ver” o que vem por aí, e começar a me adaptar.

Sou só um “usuário médio”. Não entendo da “tecnologia”. — Isto aqui não é uma “análise técnica” (muito menos, uma crítica!). — São anotações dos pontos que afetam minhas rotinas pessoais — diferentes dos hábitos da maioria dos demais usuários.

Índice

Incômodos

Painel flutuante
KDE System Settings
Tamanho e posição de janelas
Menu >> Apps >> Add to Panel (widget)
Minimizar / Restaurar / Maximizar
Wdgets e Estilos do Plasma, urgente!
Abrir aplicativos da sessão anterior
Conflito de Atalhos
Menu >> Recentes
Gwenview
Áudio de Notificações
Novos comandos?
Plasma Discover
Lags e tremuras

De volta para o futuro

Menu >> Recentes
Espaçador do Painel ajustável

Download, verificação, dd, boot
Login e senha na sessão Live

Incômodos

Painel flutuante

Reduzindo a altura do Painel Flutuante do Plasma 6.0

O Painel Flutuante é um docinho de coco! — Desperdiça espaço vertical, pois agora as janelas dos aplicativos têm de ficar mais afastadas — caso contrário, ele se retrai, gruda na margem inferior da tela, e se expande para a largura total.

Ok, é muito fácil desativá-lo e voltar ao Painel “tradicional” — mas, quem terá coragem de fazer isso? — Confesso que meu coração balançou!

Reduzi a altura do Painel, de 44 para 36 pixels, como faço em outras distros — mas no Plasma 6.0, isso deixou a data e a hora quase ilegíveis — embora a fonte seja a mesma do KDE Neon User Edition (Plasma 5.27), por exemplo.

KDE System Settings

KDE System Settings limitado à exibição em lista, no Plasma 6.0

O KDE System Settings do Plasma 6.0 ganhou uma reorganização radical — que deve despertar debates acirrados, entre os que pediam mudanças, e os que vão criticar a “irracionalidade” do reagrupamento dos itens. — É impossível agradar a todos; afinal, os agrupamentos anteriores também tinham defeitos.

O que eu perco, foi o trabalho de me acostumar. — Resta me acostumar outra vez.

Segunda parte da longa lista do KDE System Settings, no Plasma 6.0

Meu maior desgosto é não ter mais o modo de “Exibição em ícones”, que ainda mantenho nas outras distros, pois facilita “ver” as seções — ao passo que na lista-texto é difícil distinguir qualquer coisa: — É um labirinto quilométrico.

O modo de exibição em lista já existe há anos. É o “padrão” de muitas distros, há tempos, e acredito que seja mantido pela maioria dos usuários. — Tem algumas vantagens, como o destaque das alterações feitas; e a “página inicial” com as configurações mais utilizadas.

Tamanho e posição de janelas

Regras separadas de tamanho e posição de janelas, no Plasma 5 / X11

Um dos desafios da passagem do X11 para o Wayland são as regras do Kwin, em especial quanto à posição das janelas dos aplicativos. — No X11, é possível definir tamanho e posição diferentes, para a janela principal de um aplicativo — e para suas sub-janelas (configurações, por exemplo).

Me acostumei a definir a janela principal do Dolphin como um longo retângulo horizontal — e sua sub-janela de configurações no formato de uma longa janela vertical, para lidar com as extensas listas de Pré-visualização de arquivos e de itens do Menu de Contexto.

Receio que, no Wayland, isto não seja possível. — Uma perda em “liberdade de configuração” — que considero mais preciosa para obter funcionalidade (fluxo de trabalho), do que para enfeite visual.

No KDE Neon Unstable com Plasma 6.0 em sessão Wayland, os aplicativos abrem centralizados na tela. — Se eu alterar isso, também se altera o posicionamento de suas sub-janelas. — Se eu tentar alterar posição e tamanho da sub-janela, isso afeta a janela principal.

Diálogo “Renomear” do Gwenview, no Plasma 6.0

Configuro o Gwenview para abrir sempre no alto, à esquerda — e o diálogo “Renomear aquivos” abre a sub-janela lá no alto. — Pode ser arrastada, claro, mas isso é cansativo, quando se trabalha com dezenas de imagens.

No final de Fevereiro 2024, o diálogo “Renomear” do Gwenview parou de selecionar o nome dos arquivos — o que me obriga a posicionar manualmente o cursor, a cada vez. — Para mim, deixou de ser “usável”.

Menu >> Apps >> Add to Panel (widget)

Separação dos Lançadores e do Icons-only Task Manager, no Plasma 6.0

Já faz tempo, venho substituindo o tradicional Task Manager pelo Icons-only Task Manager (mais discreto) — mas sem “fixar” nele os aplicativos — ou seja, sem fazer dele um substituto dos tradicionais Lançadores (ao lado do Menu).

Desse modo, o Icons-only Task Manager me dá a visão imediata dos aplicativos que de fato estão abertos — e um modo prático de Minimizar / Restaurar qualquer um deles, com 1 clique — sem a necessidade de “alternadores de janela”, como Alt+Tab, “Present Windows” etc.

Para isso, bastava: — (a) Desafixar (unpin) os aplicativos fixados no Icons-only Task Manager, para que só apareçam quando estiverem abertos; e — (b) Abrir o Menu, selecionar os aplicativos desejados, e clicar em “Add to Panel (widget)”, para criar seus Lançadores.

Menu sem opção “Add to Panel”, no Plasma 6.0

Isso não foi possível, nas primeiras 2 sessões Live do KDE Neon Unstable, porque a maioria dos aplicativos, no Menu, não ofereciam “Add to Panel (widget)”. — Só na 3ª sessão Live, de repente, essa opção apareceu.

Depois de instalado, essa opção voltou a desaparecer, exceto para o KDE System Settings e o Dolphin. — Para os demais aplicativos, só aparecem a arcaica opção “Add to Desktop” e a opção da moda “Pin to Task Manager”.

Minimizar / Restaurar / Maximizar

Em alguns momentos, clicar no Icons-only Task Manager não minimiza a janela de algum aplicativo. — Nesses casos, é preciso clicar no “_” da Barra de Título. — Depois disso, o Icons-only volta a Restaurar / Minimizar aquele aplicativo.

Duplo-clique na Barra de Título, agora não Maximiza / Restaura. — Li em algum lugar que isso ia mesmo parar de funcionar.

Widgets e Estilos do Plasma, urgente!

Muitos dos Widgets que eu costumo usar desapareceram do “Get new widgets >> Download new Plasma widgets” — ou dão mensagem de erro quanto se tenta instalá-los — ou parecem ter-se instalado, mas não se instalaram.

Imagino que simplesmente ainda não se adaptaram ao Qt6 — e como muitos deles parecem abandonados, a única esperança é a de que novos desenvolvedores criem bifurcações (forks) e toquem pare frente.

Na KDE Store, Plasma 6 Extensions mostra só 3 itens — uma perda brutal, em relação aos milhares de widgets para o KDE 5 — e até para o KDE 4.

Um dos que sumiram é o Quicklaunch, que não sei se é o responsável pela opção “Add to Panel” no Menu. — Aliás, no Plasma 6.0 parece haver apenas 2 alternativas de Menu — enquanto nas outras distros vejo 3 alternativas.

Costumo escolher a alternativa “Application Menu” (cascading popup) — que no KDE Neon Unstable, com Plasma 6.0, muitas vezes não fecha, ao clicar fora dele. — Observo isso após clicar em algum aplicativo com o botão direito do mouse, para procurar a opção “Add to Panel”.

Desapareceram os widgets Moon Phase (by Gealach) e Weather2, que uso em todas as outras distros.

Encontrei e instalei o KDE 5 Service Menu ReImage, para adicionar ações do ImageMagick ao Menu de Contexto do Dolphin, tais como converter de PNG para JPG, redimensionar etc. — Nenhuma mensagem de erro — mas é como se não tivesse instalado.

Também não consegui instalar o “estilo” Maia Transparent. — Mensagem de erro.

Abrir aplicativos da sessão anterior

A opção de “Reabrir os aplicativos abertos na sessão anterior” veio marcada por padrão, na sessão Live do KDE Neon Unstable — mas só funcionou para lembrar minhas 2 instâncias do Conky, que eu tinha iniciado via 2 abas do Konsole:

$ conky &
$ conky -c /home/neon/.config/conky/conky2.conf &

Até onde consigo lembrar, não reabriu o Dolphin, o Kate, o Konsole etc., que deixei abertos várias vezes, intencionalmente, ao fazer Logout ou Restart.

Nas outras distros, uso as opções “Restaurar sessão salva manualmente”, tendo o cuidado de “Salvar sessão” (apenas com as 2 instâncias do Conky) — ou “Iniciar uma sessão vazia”, tendo o cuidado de colocar as 2 instâncias do Conky em “Autostart”. — Ainda não testei essas 2 opções no KDE Neon Unstable.

Conflito de Atalhos

Atalho F10 para sair do Midnight Commander conflita com F10 no Konsole

Atalhos globais F10 e F11 estão, cada vez mais, deslocando velhas práticas. — Isso começou há uns 2 anos (Plasma 5.23, acho), quando Kate / KWrite perderam o atalho F10 para alternar (on / off) o recurso “Dynamic Word Wrap”; e o atalho F11 para alternar (on / off) o recurso de numeração das linhas. — Naquele momento, bastou re-atribuir o atalho F10; e configurar o Kate / KWrite para sempre exibir a numeração das linhas.

Agora, no KDE Neon Unstable, criar um atalho F10 no Kate / KWrite não desabilita o que já existe; e quando se tenta usá-lo, uma mensagem de erro diz que ele é “ambíguo”, e nenhuma ação será realizada. — O jeito é desabilitar manualmente a outra função do atalho F10.

No Konsole, o atalho F10 não fecha mais o Midnight Commander (mc) — porque agora ele tem outra função, que se sobrepõe.

Por enquanto, o atalho F11 continua alternando a exibição do painel lateral “Informações” do Dolphin.

Menu >> Recentes

Falhas em Menu >> Recentes, no Plasma 6.0

A seção “Recentes” do Menu esquece com facilidade os aplicativos abertos em sessões anteriores. — Ainda não consegui que lembre 1 único documento aberto na sessão atual ou nas anteriores. — Para abrir as capturas de tela no Gwenview, estou clicando na notificação visual do KDE Spectacle, pois não faz sentido abrir o Gwenview para depois procurar a imagem mais recente.

Gwenview

Com frequência, o Gwenview deixa de avançar ou recuar com as setas direita / esquerda — após renomear um arquivo. — A saída é clicar sobre a imagem e, se isso não for suficiente, usar as teclas Home / End para sacudi-lo um pouco.

Áudio de Notificações

No Slackware e no Fedora, troquei a notificação visual do KDE Spectacle por uma notificação de Áudio — mas no KDE Neon Unstable, até agora, não consegui ouvir. — O Áudio funciona normalmente para o VLC e o navegador.

Tudo bem, por enquanto. — A notificação visual está sendo útil, enquanto o “Menu >> Arquivos Recentes” não funcionar.

Novos comandos?

Nas outras distros, uso o comando kf5-config --version | grep 'Qt\|KDE' para obter as versões do Qt e do Frameworks. — Ainda não encontrei um equivalente no Plasma 6.0.

Plasma Discover

Tenho o hábito de remover o Plasma Discover, das distros em que ele é instalado por padrão. — O meio mais simples seria remover o PackageKit — mas a equipe do KDE Neon insiste em que usemos o comando pkcon para fazer upgrade.

Por isso, removi apenas o Plasma Discover. — Ele voltou em uma das atualizações, e não pude evitar, pois isso bloquearia a atualização de outros pacotes. — Depois da atualização, pude removê-lo de novo (com seus backend-flatpak e backend-snap), sem qualquer problema.

Pelo Synaptic, removi o Firefox e desabilitei seu repositório PPA.

Lags e tremuras

O KDE Neon Unstable tem apresentado micro-congelamentos, ou “lags” curtos, que são meio chatos, embora não um problema sério. — Não tenho certeza se ocorrem só com o Google Chrome.

O Gimp e o Synaptic apresentam uns “flashes” tremulantes (brilhos nervosos) nas bordas, o que talvez se deva à Decoração de Janela “Transparent Oxygen”. — Nada que incomode muito, pois não atrapalha. — Só dá uma sensação chata.

Faço esses 2 registros, porque ainda não experimentei alterar qualquer configuração no Google Chrome ou de Compositor etc. — Vou devagar, por partes, uma coisa de cada vez.

De volta para o futuro

Menu >> Recentes

“Menu >> Arquivos recentes” começou a funcionar

Atualizei o KDE Neon Unstable no Sábado, 23 Dezembro — e quando iniciei de novo, no dia 25 (Natal), a seção “Menu >> Arquivos recentes” detectou a 1ª Captura de tela do dia: — Estava funcionando, enfim.

Foi-se “povoando” aos poucos — e quando reiniciei, ainda lembrava as 3 últimas, da sessão anterior. — É pouco, mas já é um progresso.

Espaçador do Painel ajustável

O “Espaçador” do Painel, agora, pode ser seu tamanho ajustado

Notei que havia desaparecido o espaçamento entre o “Lançador” do Dolphin e seu ícone no “Icons-only Taskmanager”. — Ao entrar no “Modo de Edição do Painel”, percebi que o “Espaçador” estava com largura zerada. — Aumentei sua largura para 50 pixels, e os ícones voltaram a ficar espaçados dos lançadores.

No Plasma 5, o Espaçador do Painel assume mais ou menos esse tamanho, desde que se desmarque a opção “Flexível”. — Para outros tamanhos, é preciso ativar a opção “Flexível”, que expande o Espaçador para um tamanho enorme; e dá algum trabalho redimensioná-lo manualmente, pelo ponteiro do Mouse. — Fazer o ajuste em Pixels parece bem mais prático.

****

Download, verificação, dd, boot

Verificação da ISO do KDE Neon Unstable

A página de downloads do KDE Neon oferece algumas imagens ISO e arquivos de assinatura PGP. — Recorri à página de ISOs diárias, que oferece mais opções — como as somas de verificação sha256sum, os “Manifestos” com todos os pacotes incluídos em cada ISO etc.

Particionamento do Pendrive criado pelo comando dd

No primeiro teste, “queimei” a ISO em DVD, pelo K3b.

2023-11-08  23:07   Live DVD  ISO 20231107    2023-11-09  01:10          2 h, 26 min
2023-11-14  01:56   Live USB  ISO 20231113    2023-11-16  10:25    2 d,  9 h, 33 min
2023-11-26  19:21   Live USB  ISO 20231126    2023-11-29  09:19    2 d, 14 h,  5 min
2023-11-29  09:10   Installed

Nos outros, em vez de usar o aplicativo GUI recomendado na página do KDE Neon, optei por “queimar” o Pendrive (sem partições) pelo comando dd. — Observe que o destino é “sdc” (e não “sdc1”, que não existia):

$ sudo dd if=/PATH/neon-unstable-20231126-1118.iso of=/dev/sdc bs=4M conv=fsync oflag=direct status=progress

Como resultado, o comando dd criou 2 partições — uma “tipo” iso9660; e outra “tipo” fat12. — Se eu criasse uma partição “sdc1” e direcionasse para ela o comando dd (como tentei, antes), o Pendrive não se tornava “bootável”.

Não recomendo! — pois sei muito pouco sobre isso.

Escolha do boot pelo dispositivo sdc, no UEFI Bios setup

Ao reiniciar o PC, apertei DEL para entrar no UEFI Bios setup da placa-mãe e selecionei boot pelo Pendrive (sdc) — não pela partição “sdc2”.

De acordo com as fotos e capturas de tela, o boot da 1ª sessão, em Live DVD, deve ter demorado uns 20 minutos (só lembrei de capturar a tela do Plasma aos 25 minutos). — O boot da 2ª sessão, em Live Pendrive, apresentou o ambiente de trabalho em cerca de 4 minutos. — O boot da 3ª sessão, também em Live Pendrive, exibiu o ambiente do Plasma em cerca de 4 minutos 30 segundos.

Depois de instalado, estes têm sido os tempos de boot — até exibir o ambiente Plasma com o Painel — e o uso inicial de Memória RAM:

2023-11-29   21:14   17 s
2023-11-29   21:18   19 s
2023-11-30   00:47   17 s   |   00:47 + 10 min   ->  1124 MiB
2023-11-30   05:35   17 s   |   05:34 + 10 min   ->  1124 MiB
2023-11-30   16:34   17 s   |   16:34 + 10 min   ->  1119 MiB
2023-11-30   19:33   18 s   |   19:33 + 10 min   ->  1111 MiB
2023-11-30   21:52   17 s   |   21:51 + 10 min   ->  1118 MiB
2023-12-01   02:21   16 s   |   02:21 + 10 min   ->  1168 MiB   (Plasma Discover, back again!)

São indicadores razoáveis, na comparação com as outras distros — inclusive o KDE Neon User Edition — todas na mesma máquina (dualboot / multiboot).

Login e senha na sessão Live

Configurações do SDDM, na seção “Cores e Temas”

No 1º teste Live (ISO do dia 7), o Login automático carregou uma sessão identificada como Plasma X11. — Nos demais testes Live, carregou sessão identificada como Wayland, tanto pelo KInfocentre quando pelo comando “echo $XDG_SESSION_TYPE” (que uso no 2º Conky) — embora nas configurações do SDDM ainda indique “Plasma (X11)” como sessão padrão.

Para recarregar a sessão do Plasma em sessão Live, basta fazer Logout — pois o KDE Neon Unstable vem configurado para logar de novo, de imediato.

A sessão Live vem configurada para Autologin com o usuário “neon” (senha vazia: basta Enter), que tem privilégios de Administrador. — Ao usar sudo, não pede senha. — Não existe conta Root. Para isso, use “sudo su” (e Enter).

Configurações da sessão Plasma em System >> Session >> Desktop session

A sessão do Plasma também vem configurada para reabrir os aplicativos Qt que estavam abertos ao fechar a sessão anterior.

Auto Login reiniciou apenas as instâncias do Conky e o Wellcome

Na 3ª sessão Live, isto não funcionou. — Nenhum dos aplicativos foi reaberto automaticamente — mas, para minha surpresa, as 2 instâncias do Conky reiniciaram sozinhas — embora não o Konsole, e muito menos suas 2 abas, que eu tinha usado para iniciar o Conky:

$ conky &
$ conky -c /home/neon/.config/conky/conky2.conf &

Três instâncias do “Conky2” abertas ao fazer Login

Pelo “Present windows” (CTRL+F10), descobri nada menos que 3 instâncias do meu “Conky2” em execução. — Usei o “plasma-systemmonitor” para fechar as repetições.

O usuário “neon” da sessão Live tem UID = 999 — o que o impede de escrever nas minhas partições ext4 dos SSDs internos (UID =1000). — Por isso, toda minha atividade (capturas, textos), durante as sessões Live, foi salva em uma partição Fat32 (vfat), em um 2º Pendrive. Os sistemas de arquivos vfat não guardam indicação de “proprietário”. Quando montado por um usuário “999”, seus arquivos pertencem ao usuário “999”. E quando for montado por um usuário “1000”, pertencerão ao usuário “1000”.

___________________

• Publicado em 14 Novembro 2023 e desenvolvido até 5 Dezembro 2023.

— … ≠ “•” ≠ … —

KDE Neon

Plasma 6 alpha no KDE Neon Unstable (2023)
KDE Neon upgrade 20.04 Focal Fossa (2020)
Instalação do KDE Neon 5.6 User Edition (2016)
Live KDE Neon Developer Edition Git-Unstable (2016)

PC desktop UEFI / GPT

MX Linux 23 “Libretto” KDE

noreply@blogger.com (Mboaba) — Mon, 31 Jul 2023 20:52:00 +0000

MX Linux 23 “Libretto” KDE

• O site do MX Linux oferece instruções simples e claras de “Migração” do MX-21 para o MX-23 — na verdade, uma reinstalação, preservando a partição /home e uma lista dos pacotes adicionados pelo usuário, gerada pelo “user-installed-packages” (a ser instalado no MX-21) — que depois utilizará essa lista para adicioná-los na nova instalação, com direito a revisá-la caso-a-caso.

A Wiki do MX Linux também oferece instruções para quem prefere fazer upgrade da instalação anterior (MX-21 para MX-23) — caso sinta-se habilitado a enfrentar várias tarefas por comandos e resolver eventuais problemas. — Descartei essa opção, pois alguns pacotes podem ter sido acrescentados / substituídos / removidos, e preferi garantir uma instalação “padrão” do MX Linux 23.

Optei por instalar o MX Linux 23 em uma nova partição (provisória) — testar seu funcionamento — e só depois sobrescrevê-la na partição onde estava meu MX Linux 21 (plenamente funcional).

Isto NÃO é um “tutorial”. — É só um registro do que fiz — inclusive possíveis erros (para poder entendê-los e corrigi-los, no futuro).

Índice

Pacotes instalados pelo usuário
Download, sha256sum e K3b
Sessão Live MX Linux 23
Instalação
Teste da instalação
Substituição do MX-21
Pós-instalação

Pacotes instalados pelo usuário

Lista de pacotes instalados pelo usuário no MX Linux 21

Instalei no MX-21 o “user-installed-packages” e salvei a lista dos pacotes que eu havia adicionado naquela instalação — mas também salvei várias listas de todos os pacotes instalados, usando comandos apt, dpkg, zgrep:

apt list --installed                        > 12_2023-07-31_MX21_apt-list--installed.txt
dpkg --list | grep 'ii '                    > 12_2023-07-31_MX21_dpkg--list-grep-ii.txt
dpkg --get-selections | grep -v deinstall   > 12_2023-07-31_MX21_dpkg--get-selections-grep-v-deinstall.txt
dpkg-query -l                               > 12_2023-07-31_MX21_dpkg-query-l.txt
zgrep " installed " /var/log/dpkg.log*      > 12_2023-07-31_MX21_zgrep-installed-var-log-dpkg-log.txt

Download, sha256sum e K3b

Verificação da imagem ISO do MX Linux 23 KDE pelo sha256sum

Baixei o MX-23 KDE 64 bit pelo KTorrent, verifiquei a integridade pelo sha256sum e “queimei” pelo K3b em DVD, para guardar.

Sessão Live MX Linux 23

Escolha do Idioma, Fuso horário e Teclado, antes de iniciar a sessão Live

Ao iniciar o PC pelo Live MX Linux 23, ele pré-seleciona a 3ª linha do Menu — Idioma, Teclado, Fuso horário — e a experiência já me ensinou que é melhor fazer essas escolhas antes de iniciar a sessão Live, para não perder tempo (e essas coisas já ficam configuradas para a instalação na máquina).

Ao terminar essas escolhas, ele vai para a 1ª linha do Menu de boot: — Iniciar a sessão Live MX Linux 23.

Criando uma partição proisória pelo KDE Partition Manager

Instalei Synaptic, gnome-screenshot, ttf-mscorefonts, iniciei meu próprio Conky, apliquei no ambiente Plasma KDE o Tema “MX Dark” — e pelo KDE Partition Manager criei uma partição provisória “Linux13” (29,3 GiB).

Instalação

Seleção das partições no instalador do MX Linux 23

No instalador do MX Linux 23, selecionei a partição “Linux13”, cliquei na seta para baixo no campo da coluna “Use for” (Usar como), e escolhi “/”. — Ele mudou o rótulo na coluna “Label”. — Eu podia ter mudado de volta, mas era só um rótulo provisório, sem qualquer significado no meu esquema.

Creio que alterou automaticamente para BtrFS na coluna “Formatar”, e eu cliquei na seta para baixo e escolhi ext4. — Tentei “Preservar”, mas a partição estava vazia, e por isso não tinha pasta /home que pudesse ser preservada. — Quando escolhi ext4, ele mudou a opção para “discard” (descartar), e costumo aceitar as opções-padrão, quando não sei bem o que significa.

Eu já uso BtrFS no openSUSE (Linux1), há 6½ anos, sem problema, mas não quero ter 2 distros com esse sistema de arquivos.

Anoto todos esses detalhes, dúvidas e hesitações, porque o MX Linux oferece uma quantidade enorme de recursos incomuns, que até hoje nunca explorei — pois prefiro experimentar 1 coisa de cada vez, para evitar confusão. — O instalador do MX Linux tem mudado bastante (desde o 17), o que me leva a ter muito cuidado com tudo que não entendo bem.

Tentei avançar (Next) — mas o instalador já havia detectado que o computador estava usando UEFI — e exigiu que eu escolhesse uma partição EFI.

Copiei “/boot/efi” (do aviso) e colei no campo ”Use for” — e ele automaticamente selecionou “Preserve” na coluna “Formatar” (e “noatime”, em “Opções”). — Isso é ótimo, pois ali estão as pastas EFI de outras distros, e formatar seria um desastre.

Tenho 12 distros em dualboot (ou multiboot) — e administrar essa coleção exige alguns cuidados.

Ao clicar em Avançar (Next), o instalador apresentou um resumo: — “Reusar (não formatar) sda1 como /boot/efi” — e “Formatar sda17 para usar como /”.

Desativei criar Arquivo Swap, para manter o padrão das minhas outras distros

Na tela seguinte, ofereceu instalar o Grub (em ESP) — e a criação de um Arquivo Swap de 4 GiB. — Desativei a criação do Arquivo Swap (para não ficar diferente das minhas outras distros); e deixei desativado o suporte a Hibernação.

Opções de hostname e SMB (SaMBa) no instalador do MX Linux 23

Em outra tela, propôs o nome do computador (hostname) “mx”, e o domínio “example.dom”. — Aceitei ambos. — Desativei o servidor SMB (SaMBa) para Rede MS, pois só tenho 1 PC (e nenhum Windows).

Idioma (Localização), Fuso horário, Relógio do sistema, Serviços

Em seguida, ofereceu a possibilidade de alterar o Idioma / Localização, o Fuso horário, o Relógio do sistema e o formato das horas (24h). — Mantive as opções feitas antes de iniciar a sessão Live — e o padrão UTC para o Relógio do sistema.

Um botão permite inspecionar os Serviços — e aproveitei para desativar cups, pois não tenho impressora.

Usuário, Administrador, Auto Login e alterações da sessão Live Desktop

Na tela seguinte, inseri o nome de Login e a senha do Usuário. — Ativei a conta de Administrador (Root); o Login Automático (Auto Login); e a opção de Salvar as alterações feitas na sessão Live (mantê-las na instalação final).

Ao chegar nessa tela, a instalação do MX Linux 23 no SSD já estava 93% ou 96% completa, segundo a barra de progresso — e fez uma pausa, para permitir que eu alterasse alguma configuração, antes de prosseguir. — Ao clicar em Avançar (Next), ainda foram necessários mais 6 minutos (21:21 a 21:27) para o Grub / os-prober examinar as outras 27 partições, e detectar as 12 distros instaladas.

Um tempo perdido, pois não vou usar o Grub do MX Linux como “Menu de Inicialização” — mas há muito tempo já desisti de tentar desabilitar os-prober em sessões Live de instalação de qualquer distro. — Não houve uso excessivo nem aquecimento da CPU (37ºC a 40ºC), ao contrário do que já observei em outras distros.

Desmarcando o Reboot automático antes de fechar o Instalador

Ao finalizar a instalação do MX Linux 23, tratei de desativar a opção de “Reinicializar automaticamente ao fechar o Instalador” — pois eu queria me certificar de que todos os meus arquivos estavam no Pendrive, antes de encerrar a sessão Live.

Em sessões Live, sempre uso um Pendrive, com arquivos úteis — e salvo nele as Capturas de tela e anotações da instalação. — No caso do MX Linux, espero que tudo seja preservado na pasta /home da instalação final (de fato, foi), mas prudência e canja de galinha não fazem mal a ninguém.

Observe que, durante todo o processo, é possível alternar entre as abas de “Ajuda” e de “Live Log”, do lado esquerdo. — A experiência já me mostrou o quanto é fundamental focar na “Ajuda”, e ler todas as dicas com muita atenção. — Em caso de dúvida, leia o FAQ, o Manual do Usuário, a Wiki, os Vídeos, pesquise / peça ajuda no Forum, tudo isso a um clique da tela de Boas-Vindas (MX Wellcome).

O FAQ e o Manual também estão no canto superior esquerdo da Área de Trabalho, ao lado do ícone do Instalador — como se vê na imagem abaixo:

Recursos de Ajuda na tela de Boas-Vindas da sessão Live MX Linux

O MX Linux oferece uma enorme quantidade de recursos que não são comuns em outras distros — e muitas vezes, as dicas curtas não deixam claro o significado de cada um deles, para quem ainda não os conhece por experiência própria.

Teste da instalação

Autorização de montagem de outras partições pelo Usuário, no MX Tweak

Logo após instalar o MX Linux 23 (sem partição /home separada), testei se estava funcionando bem. — Para isso, configurei só algumas coisas básicas.

Uma das principais configurações que testei, foi autorizar a montagem de partições adicionais (as que não são do MX) pelo Usuário comum — pois a exigência de senha impediria a montagem automática no início da sessão Plasma KDE.

Montagem de partições pelo Dolphin: arquivos vão sempre para “Warehouse”

Uma vez dada essa autorização, basta clicar nas partições do lado esquerdo do Dolphin, para montar pelo uDisks2 — e posso habilitar a montagem automática das partições adicionais pelo KDE System settings >> Hardware >> Removable storage >> Removable devices (deixando o fstab só para as partições do sistema).

Isso é necessário, para que os aplicativos usem uma única partição (Warehouse) — pois não faz sentido espalhar documentos nas /home de 12 distros.

Aprovada a instalação — e habilitada a montagem sem privilégios — eu já podia “movê-la” para a partição definitiva, substituindo o MX-21.

Substituição do MX Linux 21

Substituição do MX-21 pelo MX Linux 23, no GParted

Pelo GParted do Mageia, “copiei” a partição provisória “rootMX23” (29,3 GiB) e “colei” na partição definitiva “Linux12” (30 GiB), do antigo MX-21. — O GParted expande a partição “colada”, para ocupar o espaço maior.

Diferenciando rótulo e UUID das 2 partições

Mudei o rótulo (Label) da cópia para “Linux12” — para atender às configurações das outras 11 distros — e alterei o identificador UUID da “partição provisória”, para que o Grub não as confunda, e não monte ambas no boot.

Linhas da /home e do Swap copiadas do fstab da instalação anterior

Copiei as linhas de /home e Swap do fstab do MX-21 e colei no fstab do MX Linux 23. — Assim, no próximo boot o MX-23 já vai usar a /home antiga.

Devolução da prioridade de boot do EFI e atualização do Grub do Mageia

Durante a instalação, o MX Linux 23 assumiu a prioridade de boot na configuração da UEFI Bios — Pelo comando efibootmgr, devolvi a prioridade de boot para o openSUSE (cujo Grub é meu Menu de inicialização); e atualizei também o meu Grub de reserva (Mageia).

# efibootmgr
BootCurrent: 0003
Timeout: 1 seconds
BootOrder: 0007,0000,0003,000A,0002,0005,000E,0004,0006,000B,000F,0001,0010,0011
Boot0000* opensuse      HD(1,GPT,329cbd71-80e8-43e9-a12c-126aac943cfa,0x800,0x400000)/File(\EFI\OPENSUSE\GRUBX64.EFI)
Boot0001* debian        HD(1,GPT,329cbd71-80e8-43e9-a12c-126aac943cfa,0x800,0x400000)/File(\EFI\DEBIAN\SHIMX64.EFI)
Boot0002* Fedora        HD(1,GPT,329cbd71-80e8-43e9-a12c-126aac943cfa,0x800,0x400000)/File(\EFI\FEDORA\SHIM.EFI)0000424f
Boot0003* mageia        HD(1,GPT,329cbd71-80e8-43e9-a12c-126aac943cfa,0x800,0x400000)/File(\EFI\MAGEIA\GRUBX64.EFI)
Boot0004* pclinuxos     HD(1,GPT,329cbd71-80e8-43e9-a12c-126aac943cfa,0x800,0x400000)/File(\EFI\PCLINUXOS\GRUBX64.EFI)
(...)

# efibootmgr -o 0000,0003,000A,0002,0005,000E,0004,0006,000B,000F,0001,0010,0011,0007
BootCurrent: 0003
Timeout: 1 seconds
BootOrder: 0000,0003,000A,0002,0005,000E,0004,0006,000B,000F,0001,0010,0011,0007
Boot0000* opensuse      HD(1,GPT,329cbd71-80e8-43e9-a12c-126aac943cfa,0x800,0x400000)/File(\EFI\OPENSUSE\GRUBX64.EFI)
Boot0001* debian        HD(1,GPT,329cbd71-80e8-43e9-a12c-126aac943cfa,0x800,0x400000)/File(\EFI\DEBIAN\SHIMX64.EFI)
Boot0002* Fedora        HD(1,GPT,329cbd71-80e8-43e9-a12c-126aac943cfa,0x800,0x400000)/File(\EFI\FEDORA\SHIM.EFI)0000424f
Boot0003* mageia        HD(1,GPT,329cbd71-80e8-43e9-a12c-126aac943cfa,0x800,0x400000)/File(\EFI\MAGEIA\GRUBX64.EFI)
(...)

Grub do openSUSE, agora com dois MX Linux 23, em sda e sdb

Depois, entrei no openSUSE e atualizei seu Grub, que voltou a ser o “principal”.

A atualização do Grub do Mageia levou 3’11’’ (23:05:47 a 23:08:58);
A atualização do Grub do openSUSE levou 31’’ (23:20:01 a 23:20:32);
A atualização do Grub do MX Linux levou 2’01’’ (13:10:40 a 13:12:41), ainda com os-prober.

Pós-instalação

Início do MX-23 com as configurações da /home do MX-21

Com a partição /home “herdada” do MX-21, o MX-23 já iniciou com o antigo papel-de-parede, 2 instâncias do Conky, widgets Moon Phase e Weather — e inúmeras configurações, que não eu precisaria repetir. — Faltavam poucas coisas.

Instalei os pacotes aha, html2text, screenfetch, usados pelo 2º Conky — e criei os agendamentos de registro (RAM, Versões dos softwares) e de limpeza do cache:

$ crontab -l
@reboot echo ' ' > done.txt
@reboot sleep 600; bash RAM.sh
@reboot sleep 780; bash VERSIONS.sh
@reboot sleep 900; find ~/.cache/ -type f -atime +365 -delete

Tempo de boot e uso inicial de RAM do MX Linux 23 KDE

Ao reiniciar, o boot do MX Linux levou 22’’, até a exibição do Painel do KDE Plasma (acima, à esquerda) — a mesma média registrada pelo MX-21 em Junho.

Aos 10 minutos uptime (iddle), o script RAM.sh registrou uso de 1197 MiB (praticamente o mesmo da captura, acima, à direita). — Isso era 27% mais do que os 940 MiB registrados pelo MX-21 em Junho — ou quase 24% a mais do que a média de 967 MiB nas 6 medidas anteriores.

Baixei e instalei o Google Chrome e o GoogleEarth. — Os repositórios do Google foram adicionados automaticamente, no processo:

$ history

  456  2023-08-01_00-12-59 date; sudo apt install ~/Downloads/google-chrome-stable_current_amd64.deb; date
  458  2023-08-01_00-19-38 wget https://dl.google.com/dl/earth/client/current/google-earth-stable_current_amd64.deb -O google-earth-stable.deb
  459  2023-08-01_00-21-04 date; sudo dpkg -i google-earth-stable.deb; date

Deletando a “partição provisória” pelo KDE Partition Manager

Pelo KDE Partition Manager, deletei a “partição provisória” — que não tinha mais utilidade, agora que a cópia na partição definitiva já foi testada e aprovada.

Alterei os repositórios para espelhos mais rápidos, pelo MX Repo Manager.

Configurei o KWrite para sempre exibir a numeração das linhas — pois nas versões mais novas do KDE a tecla F11 conflita com o atalho global — e configurei a tecla F10 para alternar “Dynamic Word Wrap” (on / off).

No MX-21, o Kate (20.12.2) e o KWrite ainda tinham esses atalhos (F10, F11) — mas no MX Linux 23, o Kate e KWrite (22.12.3) vêm sem eles.

Emparelhamento do celular pelo KDE Connect

Autorizei as portas para o KDE Connect, solicitei emparelhamento pelo celular, aceitei no MX Linux — e baixei as fotos da instalação.

Removendo o PackageKit (e o Plasma Discover)

Apareceu mais um aviso de atualizações na bandeja do sistema, e lembrei de remover o PackageKit — o que leva embora também o Plasma Discover (não uso).

Com isso, elimino avisos chatos (atualizo minhas distros 1 vez por semana, aos Domingos) — e “nivelo” o comportamento de todas elas — pois no Arch, no Void, no Slackware, por exemplo, não tenho PackageKit verificando atualizações (e elevando o uso de recursos). A “comparação” torna-se mais objetiva.

O PackageKit usa o gerenciador de pacotes de cada distro (apt, zypper, dnf) — em parceria com o Plasma Discover, no caso do KDE (ou outras Lojinhas, em outros DEs). — A utilidade dessa dupla dinâmica é fazer com que pareça simples o gerenciamento de todo tipo de pacotes, inclusive Snaps e Flatpaks (que têm seus próprios gerenciadores).

Nas distros de base Debian, também costumo remover o unattended-upgrades, que faz “atualizações de segurança”, sem perguntar, nem avisar — e registra em um log separado, o que dificulta meu acompanhamento do que acontece. — Esse pacote não veio no MX Linux 23.

Verificação da conexão e dos espelhos (Mirrors), num dia de Domingo

Em lugar disso tudo, executo um apt update, para ver se a conexão e os espelhos (Mirrors) estão Ok — caso contrário, não avanço — e um apt list --upgradable para ver o que será atualizado.

Depois, uso o Synaptic para “aplicar” essas atualizações — após examinar as seções “Obsoleto”, “Auto-Removível”, “Configurações Residuais” etc.

Pesquisa no Histórico do Synaptic

O Synaptic também é muito prático para pesquisar, instalar, remover pacotes — e seu Histórico permite pesquisar exatamente quando cada pacote foi instalado, removido ou atualizado, ao longo do tempo. — Por isso, infelizmente não tenho usado o MX Package Installer (só o MX Repo Manager).

Instalando os pacotes que faltavam

Com ajuda da lista gerada pelo user-installed-packages, instalei os “7 pacotes” que ainda faltavam: — kruler, kstars, npm, speedtest-cli, tree, xsane, yt-dlp.

Seria mais simples e rápido fazer isso pelo próprio user-installed-packages — mas preferi o Synaptic, para manter o Histórico unificado. — Só ficaram fora do Histórico do Synaptic, a instalação inicial dele mesmo, e do gnome-screenshot (pelo apt, ainda na sessão Live); e mais tarde, a do Chrome e do GoogleEarth, pelos comandos apt e dpkg.

A instalação do npm envolveu 357 pacotes — o que elevou o total de pacotes instalados, de 2415 para 2793, ao final do que parecia ser, só, “instalar 7 pacotes”. — Mas são dependências pequenas, e o espaço ocupado em disco aumentou apenas 543 MiB (de 8,12 GiB para 8,65 GiB): média de 1,4 MiB, cada.

Ainda é muito menos do que os 3686 pacotes instalados no Debian testing — e mais perto dos 2967 instalados no KDE Neon, uma distro “buntu-based” enxuta.

Em Março 2020, a instalação do npm no Debian testing envolveu 285 pacotes — e em Abril 2020 a instalação do npm no KDE Neon envolveu apenas 70 pacotes.

Dica para desabilitar os-prober

Me confundi com alguns ajustes próprios do MX Linux 23, quando tentei desativar o os-prober. — Pedi ajuda no Fórum, e logo recebi a dica: — Anular aquelas 3 linhas em /etc/default/grub, que remetem a /etc/default/grub.mx-defaults.

Depois disso, a atualização do Grub do MX Linux levou apenas 20’’, e no openSUSE levou apenas 26’’ — mas para isso também contribuiu a eliminação da outra cópia do MX-23 na “partição provisória”, pois o tempo é proporcional ao número de distros, e ao tamanho dos arquivos /boot/grub/grub.cfg dentro delas. — Por isso, não faz sentido que todas produzam arquivos enormes. — De qualquer modo, o Grub do openSUSE Tumbleweed é o único que consegue carregar todas as outras; e o do Mageia é o único que consegue detectar corretamente o openSUSE, instalado em partição BtrFS (sem partição /boot separada).

Editando /etc/hosts e /etc/hostname no MX Linux 23

Substituí “mx” por “Linux12” nos arquivos hosts e hostname.

Isso não pôde ser feito pelo comando $ sudo nano. — Tive de usar o su e executar # nano. — Foi bom ter habilitado a conta Root.

Configurando apt / Synaptic para deletar pacotes baixados, depois de instalados

Finalmente, lembrei de configurar o apt para deletar os pacotes baixados, depois de serem instalados. — Fiz isso pelo Synaptic >> Settings >> Preferences >> Files — e aproveitei para clicar no botão “Delete Cached Package Files”.

Ainda não tinha acumulado muita coisa em /var/cache/apt/archives — e o espaço ocupado em disco caiu apenas de 8,65 GiB para 8,48 GiB — mas esse cache nunca teve utilidade para mim.

Substituição do Weather pelo Weather2

Removi o antigo Weather widget (1) — que ainda funcionava em versões antigas do KDE Plasma — e instalei o Weather widget-2.

Instalação e teste do corona-cli

Pelo comando “sudo npm i -g corona-cli@latest”, instalei o corona-cli.

Desabilitando “Hide docks”, para o Gimp exibir o Toolbox

Instalar uma distro Linux nunca é uma experiência completa, se a gente não deparar com pelo menos 1 problema. — O Gimp 2.10.34 abriu sempre sem o Toolbox, e eu tinha de abri-lo manualmente, todas as vezes (2 cliques!). — Além disso o Toolbox também não minimizava, ao minimizar o Gimp.

Depois de alguns dias, acabei encontrando a solução: — Desabilitar a opção “Hide docks”, no submenu “Janelas”.

Integração de tema GTK-KDE com o pacote libreoffice-kf5

Ainda me incomodava a interface do LibreOffice, com menus em letrinhas miúdas e finas sobre fundo “cinzento-pré-INPS”. — Comentei com os amigos, e recebi a dica de instalar o pacote libreoffice-kf5, de integração de tema GTK-KDE.

___________________
• Publicado em 31 Julho 2023 e desenvolvido até 6 Agosto 2023.

— … ≠ “•” ≠ … —

MX Linux

PC desktop UEFI / GPT

Upgrade do Mageia 8 para Cauldron (Mageia9)

noreply@blogger.com (Mboaba) — Wed, 05 Jul 2023 11:22:00 +0000

Mageia Cauldron identifica-se como “Mageia 9”, no momento •

Cauldron é a versão de desenvolvimento do Mageia — onde se prepara o próximo lançamento — depois, o lançamento seguinte — e assim por diante.

Comporta-se como um lançamento contínuo (rolling release) — mas não é feito para isso, nem se recomenda para uso comum. — É para desenvolvedores e testadores.

Mageia adverte que o “Cauldron pode quebrar seu computador, devorar seus dados, incendiar sua casa ou matar seus gatinhos”. — Se você precisa de uma distro “confiável” para o seu trabalho, fique sempre com a versão “estável”.

Em suma: é a versão de teste. — É como instalar Mageia 9 beta2, para ver o desenvolvimento final da próxima versão — e não parar mais de acompanhar os desenvolvimentos posteriores... Mageia 10... Mageia 11... etc.

Em vez de instalar, optei por fazer upgrade do meu Mageia 8 (stable) para Cauldron (testing) — de modo a preservar, na medida do possível, os pacotes que adicionei nos últimos 2 anos, as configurações em /etc e tudo mais.

Isto não é um “tutorial”! — É só um registro para lembrar o que fiz, e como fiz — inclusive, erros... e desobediência às recomendações oficiais.

Índice

Roteiro
Bem-vindo ao Mageia Cauldron
Ajuste fino
Escovando bits
Conclusões
Por que Cauldron?
E por que não via DNF?

Roteiro

Atualização do Mageia 8, antes de iniciar o upgrade para Cauldron

Leia as recomendações oficiais com atenção.

Basicamente — pelo urpmi:

Atualizar o Mageia estável
Remover os Repositórios da versão estável
Adicionar os Repositórios do Cauldron
Testar o upgrade (download e simulação)
Fazer o upgrade

Por distração, pulei o teste — e fiz logo o upgrade — o que é um perigo!

Em negrito, no histórico do bash — que não registrou a atualização inicial (imagem acima: 11:35):

# history
  776  2023-07-04_11-42-32  # dnf --version
...
  784  2023-07-04_12-25-49  # rpm -qa | sort > packages-installed-Mageia8.txt
...
  786  2023-07-04_13-01-43  # urpmi.removemedia -a
  788  2023-07-04_13-02-51  # urpmi.addmedia --distrib 'http://mageia.c3sl.ufpr.br/distrib/cauldron/x86_64/'
  790  2023-07-04_13-06-21  # systemctl stop dnf-makecache.service
  791  2023-07-04_13-06-41  # systemctl stop dnf-makecache.timer && systemctl daemon-reload
  792  2023-07-04_13-11-02  # date; urpmi --auto-update --auto --force; date
  793  2023-07-04_13-10-03  # script upgrade_log-1.txt
...
  797  2023-07-04_13-44-26  # rpm -qa | sort > packages-installed-Mageia9-Cauldron.txt
  799  2023-07-04_13-49-40  # urpmi --clean

Acima: - Depois do urpmi --auto-update, verifiquei se o dnf estava instalado (estava) — pois neste caso podia ser bom parar o dnf-makecache pelo systemctl. — Isso era uma recomendação antiga (de que dnf-makecache podia travar o upgrade via urpmi), mas não sei se ainda é necessária.

Pelo comando rpm, salvei uma lista dos pacotes instalados no Mageia 8.

Removi os repositórios do Mageia 8 pelo comando urpmi.removemedia -a.

Comando urpmi.addmedia para Cauldron x86_64 de um espelho específico

Adaptei o comando urpmi.addmedia para adicionar Cauldron e a arquitetura x86_64 — de um espelho específico.

Mecanismos de escolha automática de espelhos mais “próximos”, ou “mais responsivos”, são muito úteis para quem começa a usar distros Linux, ou não quer gastar tempo e neurônios — mas “o melhor da hora”, nem sempre é o melhor a médio e longo prazo. — Já usei dúzias de espelhos do Brasil e do exterior, e sei em quais posso confiar, levando em conta também as conexões até a minha cidade.

Parei o serviço dnf-makecache — e iniciei o Typescript, para registrar todas as mensagens do upgrade. — O histórico só registra o comando Typescript no final da gravação, ou seja, após o comando de upgrade (embora com o horário anterior).

Pelo comando rpm, salvei uma nova lista dos pacotes instalados — agora, no “Mageia 9” Cauldron — e limpei o cache de pacotes baixados pelo urpmi.

Dolphin parou de funcionar no meio do upgrade para Cauldron

Recomenda-se não fazer o upgrade do Mageia dentro de uma sessão desktop, mas é claro que não obedeci. — Perto do final, o Dolphin não conseguia mais abrir outras pastas — mas o Kate e o gnome-screenshot continuaram gravando seus arquivos normalmente, e pude documentar o processo todo, sem lacunas.

urpmi alterna download e instalação (e remoção!), por grupos de pacotes

O upgrade, propriamente dito, se realizou em 11 minutos (13:11 às 13:22), com uma conexão de 480 “megas” (480 Mbit/s = 57,22 MiB/s), alternando download, instalação (e remoção!) de grupos de pacotes.

Script started on 2023-07-04 13:10:03-03:00

# date; urpmi --auto-update --auto --force; date
Tue  4 Jul 13:11:02 -03 2023

(...)

You should restart your computer for dbus, glibc, kernel-desktop, systemd
Tue  4 Jul 13:21:51 -03 2023

exit

Script done on 2023-07-04 13:22:18-03:00

Download, instalação e remoção de grupos de pacotes pelo urpmi

Ao contrário do upgrade pelo dnf — que baixa todos os pacotes de uma vez, e depois reinicia o PC para aplicar as alterações fora do ambiente desktop — o urpmi baixa e instala um grupo de pacotes de cada vez, ao mesmo tempo em que já vai removendo os grupos de pacotes substituídos.

Isso é um perigo — caso haja qualquer falha ou interrupção no meio do processo!

Por isso, é recomendado fazer o download de todos os pacotes, seguido de um teste que apenas simula o upgrade, para detectar possíveis falhas — antes de realmente fazer o upgrade — mas por distração, não notei que eu tinha esquecido de adicionar esses 2 parâmetros ao comando:

 # urpmi --auto-update --auto --download-all --test

Felizmente, a energia elétrica não caiu durante o processo — e não houve falha no download de nenhum pacote.

Foi por decisão consciente que — contra todas as recomendações — decidi fazer o upgrade dentro da sessão KDE Plasma, e com vários aplicativos abertos.

Mas as falhas e erros devem-se ao fato de que li coisas demais: — instruções de upgrade para Cauldron, instruções de upgrade do Mageia 7 para Mageia 8, instruções de upgrade pelo urpmi e pelo dnf — e fiz uma bela confusão com esse excesso de leituras, sem parar para resumir um roteiro simples e claro, e conferir com atenção, antes de começar.

Para instalar o Arch pela primeira vez, li 300 vezes mais — mas tive o cuidado de resumir um roteiro simples e claro. — Agora, resolvi fazer o upgrade, e agi de improviso, o que não é recomendável.

Por isso, registro aqui apenas o que fiz — não um “roteiro ideal” — e evito falar de outros métodos de upgrade (para não confundir, e porque não testei).

Bem-vindo ao Mageia Cauldron

Grub do Mageia Cauldron consegue detectar e carregar openSUSE em BtrFS

Ao reiniciar o computador, o Grub do Mageia Cauldron tinha assumido a prioridade de boot no UEFI Bios.

A sessão KDE exibiu o Painel aos 20 segundos uptime (Auto Login). — A média das 6 inicializações seguintes foi de 17 segundos até exibir o Painel. — Ver “Conclusões”, adiante.

Eu ainda não tinha re-configurado os repositórios do Google — mas o Chrome e o GoogleEarth não foram removidos.

O MSEC tinha voltado à configuração padrão — “Enable periodic security checks”, que desativei outra vez — mas manteve o acesso que eu tinha concedido ao KDE Connect.

Atualização do Grub do openSUSE, meu Menu de inicialização

O Grub do Mageia Cauldron continua capaz de detectar o openSUSE, instalado em sistema de arquivos BtrFS, sem partição de /boot separada. — Devolvi a prioridade de boot ao openSUSE pelo efibootmgr — e atualizei seu Grub para detectar o novo Mageia Cauldron.

KDE-PIM a todo vapor, com 17+ processos Akonadi y otras cositas más

Aos 10 minutos (iddle) da 2ª sessão do Mageia Cauldron KDE, o uso de Memória RAM ficou em 1.384 MiB — 30% acima do uso no Mageia 8.

Isso me alertou de que o KDE-PIM estava em plena atividade, com 17+ processos Akonadi — entre outras coisas, que eu tinha desativado / removido do Mageia 8.

Isso também deu uma pista para o motivo de o número de pacotes instalados ter aumentado em 323 — de 2.696 no Mageia 8 para 3.019 no Mageia Cauldron.

A causa talvez seja porque fiz upgrade com o parâmetro --force, ausente nas recomendações oficiais: — “force invocation even if some packages do not exist”. — Como não se podem invocar pacotes inexistentes, suponho que queira dizer “pacotes não-instalados”.

Remoção de dezenas de pacotes do KDE-PIM, pelo rpmDrake

Pelo rpmDrake, pesquisei PIM, Kmail, KAddressbook, Kontact, KOrganizer, KNotes, KAlarm, Akonadi etc., e removi quase tudo — com toneladas de dependências — poupando só o que ameaçasse remover pacotes úteis, ou quebrar o ambiente KDE.

Importante: - Preservo sempre o baloo e o baloo-widgets (+2 bibliotecas), que são indispensáveis ao ambiente Plasma KDE.

Removi também o dnf, que não pretendo usar.

Enfim, executei o urpme --auto-orphans para eliminar o que sobrou.

Com isso, o número de pacotes instalados recuou para 2.862 — o que ainda é 166 a mais do que eu tinha no Mageia 8 — e nos 2 boots seguintes, o uso de Memória RAM aos 10 minutos (iddle) recuou para 1015 MiB e 1.004 MiB, o que está mais próximo dos 1.068 MiB do Mageia 8 no mês anterior.

Variações de até 40 MiB ocorrem a cada segundo — por isso, não vale a pena levar muito a sério pequenas diferenças no “uso inicial de Memória RAM” entre 2 distros — e se você tem mais de 4 GB RAM, não perca tempo com isso. Use a distro e o DE que quiser, e seja feliz!

Desabilitando alguns serviços do Plasma Search

Essa redução de uso de Memória RAM também se deveu, em parte, à desativação de vários Background Services, Desktop Effects e serviços do Plasma Search que eu não utilizo — mas que tinham sido reativados no upgrade para Cauldron.

Substituição do widget Weather pelo Weather2

Substituí o velho widget Weather — que ainda funcionava com a versão antiga do KDE Plasma — pelo Weather2.

Dynamic Word Wrap e Show Line Numbers no KWrite

As versões mais recentes do KWrite (e do Kate) perderam os atalhos para alternar (on / off) Dynamic Word Wrap (F10) e Show Line Numbers (F11). — F10 pode ser configurado manualmente — ao passo que F11 agora conflita com o atalho global, mas bastou configurar para sempre exibir a numeração das linhas.

speedtest-cli e corona-cli funcionam normalmente

O speedtest-cli funciona normal (com as limitações by Ookla).

O corona-cli só precisou ser atualizado (por comando npm), pois há tempos eu não fazia isso.

Tue  1 Nov 13:43:02 -03 2022                               Tue  4 Jul 16:50:51 -03 2023

medium "Core Release (distrib1)" is up-to-date             medium "Core Release" is up-to-date
medium "Core Updates (distrib3)" is up-to-date             medium "Core Updates" is up-to-date
medium "Nonfree Release (distrib11)" is up-to-date         medium "Nonfree Release" is up-to-date
medium "Nonfree Updates (distrib13)" is up-to-date         medium "Nonfree Updates" is up-to-date
medium "Tainted Release (distrib21)" is up-to-date         medium "Tainted Release" is up-to-date
medium "Tainted Updates (distrib23)" is up-to-date         medium "Tainted Updates" is up-to-date
medium "Core 32bit Release (distrib31)" is up-to-date      medium "Core 32bit Release" is up-to-date
medium "Core 32bit Updates (distrib32)" is up-to-date      medium "Core 32bit Updates" is up-to-date
medium "Nonfree 32bit Release (distrib36)" is up-to-date   medium "Nonfree 32bit Release" is up-to-date
medium "Nonfree 32bit Updates (distrib37)" is up-to-date   medium "Nonfree 32bit Updates" is up-to-date
medium "Tainted 32bit Release (distrib41)" is up-to-date   medium "Tainted 32bit Release" is up-to-date
medium "Tainted 32bit Updates (distrib42)" is up-to-date   medium "Tainted 32bit Updates" is up-to-date
medium "earth_x86_64" is up-to-date
medium "chrome_x86_64" is up-to-date

2023-07-05 12:07:53

# urpmi.addmedia --update chrome_x86_64 http://dl.google.com/linux/chrome/rpm/stable/x86_64
adding medium "chrome_x86_64"
    http://dl.google.com/linux/chrome/rpm/stable/x86_64/media_info/synthesis.hdlist.cz

# rpm --import https://dl-ssl.google.com/linux/linux_signing_key.pub

# urpmi.addmedia --update earth_x86_64 http://dl.google.com/linux/earth/rpm/stable/x86_64
adding medium "earth_x86_64"
    http://dl.google.com/linux/earth/rpm/stable/x86_64/media_info/synthesis.hdlist.cz

Acima: - Os “canais” (medium; media; distrib) do Mageia Cauldron, adicionados pelo urpmi.addmedia, são os mesmos que eu tinha no Mageia 8.

Só alguns desses “canais” vieram habilitados, ao instalar o Mageia 8 (distrib1, 3, 11, 13, 36, 37, se não me engano); e os outros, habilitei depois. — Isto sugere que, ao “remover todos”, essa configuração foi preservada; e ao usar o comando urpmi.addmedia para escolher “Cauldron”, ele já sabia quais “canais” deviam ser habilitados.

Só precisei adicionar os repositórios do Google e obter sua chave pública.

No caso do GoogleEarth, mais tarde substituí “http” por “https”, só para seguir a versão atual da Wiki — mas isso não trouxe nenhuma atualização do pacote — e a busca por cidades, ruas etc. continua sem funcionar (como já não funcionava no Mageia 8).

Tudo mais — o KDE Plasma, os Aplicativos KDE e demais aplicativos que eu já tinha no Mageia 8 — continua funcionando no Mageia Cauldron.

No Gimp, mantiveram-se inúmeras configurações — mas outras, tive de refazer, tal como já havia acontecido, por exemplo, na transição para o Gimp 2.10.

É possível que eu encontre mais alguma coisa, em outros aplicativos, que ainda não abri até o momento. — Faz parte da vida.

Falha em “Abrir com Gimp”, no Menu de contexto do Gwenview

O único problema novo (falta solucionar!), é que no Menu de contexto do Gwenview, ao clicar em “Abrir com Gimp”, abre uma nova instância do Gwenview. — Isso é chato, pois uso muito, no dia-a-dia. — Mas no Dolphin, o Menu de contexto “Abrir com Gimp” funciona sem qualquer problema.

O yt-dlp está encontrando muitos “erros”, embora a versão seja de Junho 2023 — mas não tenho usado outras distros, para comparar. — Talvez o Youtube tenha colocado novas barreiras, a serem dribladas pela próxima versão do pacote.

Ajuste fino

“MyPlaces” importado do Arch Linux

No GoogleEarth, importei os “Meus Lugares” do Arch Linux, movi seu conteúdo para os “Meus Lugares” do Mageia, reorganizei e salvei. — Depois salvei uma cópia na minha partição de documentos (Warehouse, com backups semanais).

Icons-only Taskbar, mais discreto

Agora que estou no Mageia Cauldron por um longo período, troquei o Taskmanager (Gerenciador de tarefas) pelo “Icons-only Taskmanager” — que é mais discreto e facilita trabalhar com muitas janelas — em ordem “manual” (Sort: Manually) e sem agrupar (Do not group).

Ocupação da pasta ~/.cache

Meia hora antes do upgrade, no dia 4 Julho, a ocupação da partição /home estava em 6,47 GiB — mas no dia 10 (menos de uma semana depois!). já tinha chegado a 11,6 GiB — um aumento vertiginoso, que nunca vi em nenhuma distro.

Pelo Filelight, verifiquei que havia 4,3 GiB em ~/.cache/tracker3; e mais 1,5 GiB em ~/.cache/thumbnails. — Costumo deletar manualmente os Thumbnails, que proliferam (e se acumulam para sempre), quando vejo alguma partição /home chegar perto da lotação máxima; — mas nunca vi nem ouvi falar de tracker.

Numa pesquisa rápida, vi que é um indexador do Gnome — equivalente, talvez, ao baloo_file do KDE (que removo sempre que encontro). — Segundo meus registros, o tracker e o tracker-miners foram instalados como dependências do Foliate, em Setembro 2020 (mas ficaram quietos, até a semana passada).

Tentei remover o tracker, mas o urpme avisou que isso removeria 147 pacotes — incluindo Gimp, Chrome, LibreOffice, lsb, mate-polkit (?), plasma-desktop, rpmdrake, Xsane — a maioria dos quais, já estavam instalados, antes do tracker, e por isso é difícil acreditar que não possam viver sem ele.

Mas consegui remover o tracker-miners — e aproveitei para remover o gnome-desktop e o Firefox, que não uso. — Depois disso, não apareceram novos arquivos na pasta ~/.cache/tracker3 (que esvaziei).

Esvaziar a pasta ~/.cache/thumbnails foi mais complicado, pois eram tantos, que o rm pediu arrego — mas o comando find conseguiu. — E restavam muitas outras subpastas em ~/.cache, que eu não iria deletar em massa, sem pesquisar o que são, e as possíveis consequências.

Acabei ficando com um meio-termo: — Deletar tudo que não é acessado há mais de 1 ano — e criei um agendamento para fazer isso 15 minutos após o boot (para não interferir no registro do uso de RAM, aos 10 minutos):

$ crontab -l
@reboot echo ' ' > done.txt
@reboot sleep 600; bash RAM.sh
@reboot sleep 780; bash VERSIONS.sh
@reboot sleep 900; find ~/.cache/ -type f -atime +365 -delete

Depois dessas manobras, a ocupação da pasta /home caiu para 4,12 GiB — e, o que é mais importante: — parou de aumentar naquele ritmo alucinado.

Resolvi mover meus scripts para ~/bin — e eles continuaram funcionando pelo Conky e por comandos manuais, pois a pasta já estava no $PATH — mas o cron não os encontrou mais.

Em geral, o PATH do ambiente cron é /usr/bin:/bin, e por motivos de segurança, ele não lê o perfil de usuário (.bash_rc, .bash_profile). — Pode-se redefinir o PATH no início do crontab, mas para evitar um longo estudo (e possíveis erros), achei mais simples apenas indicar o “caminho” dos scripts:

$ crontab -l
@reboot echo ' ' > done.txt
@reboot sleep 600; bash /home/flavio/bin/RAM.sh
@reboot sleep 780; bash /home/flavio/bin/VERSIONS.sh
@reboot sleep 900; find ~/.cache/ -type f -atime +365 -delete

Escovando bits

Não consegui remover Flatpak. — O comando urpme avisa que isso implica em remover partes do KDE. — Segundo meus registros, Flatpak foi instalado por uma simples atualização do sistema, em Julho 2020.

Também não pude remover PackageKit. — O comando urpme diz que isso implica em remover Dolphin e outras coisas essenciais. — Isso parece loucura, e desconfio, cada vez mais, que se deva a alguma configuração exagerada, de considerar pacotes “sugeridos” como se fossem “dependências” cruciais (como no openSUSE).

Fiquei alarmado ao perceber que, às vezes, urpme desinstala pacotes sem pedir confirmação — e ainda não sei, em quais casos — o que torna essa brincadeira um tanto perigosa, até que eu aprenda mais.

Um caso típico são os metapacotes “task” — como o task-plasma5, que deixou órfãos ksystemstats e plasma-systemmonitor.

Para não perder a comodidade do comando urpme --auto-orphans, tive de marcá-los como “instalados explicitamente”. — Para isso, basta tentar reinstalá-los, pois nesse caso o urpmi limita-se a retirá-los da lista de pacotes órfãos. — Este comando facilita a tarefa:

# date; urpmi $(urpmq --auto-orphans -f); date
Thu 13 Jul 14:23:53 -03 2023
Packages kernel-desktop-6.3.9-2.mga9.x86_64, ksystemstats-5.27.5-1.mga9.x86_64, plasma-systemmonitor-5.27.5-1.mga9.x86_64 are already installed
Marking kernel-desktop as manually installed, it won't be auto-orphaned
Marking ksystemstats as manually installed, it won't be auto-orphaned
Marking plasma-systemmonitor as manually installed, it won't be auto-orphaned
writing /var/lib/rpm/installed-through-deps.list
Thu 13 Jul 14:23:55 -03 2023

Infelizmente, isso também foi aplicado ao Kernel 6.3.9-2 — que agora não será mais eliminado automaticamente, na hora devida. — Vou ter de removê-lo, eu mesmo, quando não for mais necessário.

Verificando pelo rpmDrake os meta-pacotes instalados

Um exame pelo rpmDrake, filtrando “Meta packages”, mostrou que ficaram apenas task-pulseaudio, basesystem, task-obsolete, task-x11 e task-codec-video — nos quais prefiro não mexer, por enquanto.

Importante: - O usuário do Mageia não precisa perder tempo com esse tipo de minúcias, pois o sistema é feito para ser amigável e sólido. — Faço essas coisas só para explorar as entranhas da distro e entender seus mecanismos internos, como um guri que desmonta os brinquedos. — Com 16 GB RAM e uma partição de 30 GiB, não há necessidade de “economizar bits”.

Opção “Imprimir para um arquivo”, no LibreOffice Calc

Eu já tinha removido hplip desde Outubro 2020 — e agora removi o que havia sobrado do cups — um teste que eu queria fazer há muito tempo, pois me desfiz de minha última impressora há mais de 20 anos.

Após reiniciar, o Chrome continua imprimindo em PDF (CTRL+P) — e no LibreOffice ainda funciona o “Export as PDF” (que prefiro). — Para “imprimir” no LibreOffice, preciso selecionar manualmente “Print to file”, enquanto não descobrir como mudar o padrão “Generic printer”

Conclusões

Quadro 1 - Estado das minhas distros em 11 Junho 2023

Quadro 1 - A “usabilidade” do Mageia Cauldron, para mim, não se alterou, em relação ao Mageia 8 do mês passado, quando fiz a última verificação do “estado” das distros instaladas no meu PC. — Sinto um impulso de afirmar que, agora, o Mageia se tornou uma de minhas “distros preferidas” — mas a razão fria me garante que isso é entusiasmo com “brinquedo novo”.

Quadro 2 - Mageia Cauldron face às outras distros no mês passado

Quadro 2 - Tudo no Mageia Cauldron está “mais atual” — e vai continuar “sempre atual”, pois Cauldron é sinônimo de “atualização permanente” — mas o grande “ganho” é que “não perdi nenhuma usabilidade” que eu tinha antes.

Isso não é pouca coisa. — Significa que todo novo aprendizado pode me levar para frente, em vez de perder tempo consertando retrocessos. — Com a diferença, de que uma distro “atual” me anima muito mais a investir no aprendizado e solução de problemas, do que uma distro “estagnada” durante 2 anos.

Boot times:

2023-07-04   18:38   Mg   18’’
2023-07-05   07:25   Mg   17’’
2023-07-06   10:26   Mg   17’’
2023-07-09   14:04   Mg   17’’
2023-07-10   14:48   Mg   17’’
2023-07-11   17:29   Mg   18’’    average 17’’

RAM usage 10 min uptime (iddle):

2   1015  MiB
3   1004  MiB
4    998  MiB
5   1011  MiB
6   1003  MiB
7   1007  MiB
8   1006  MiB    average: 1006  MiB

Other SO's - just 1 sample, back in 11 June:

Void                      878  MiB
PCLinuxOS                 921  MiB
Slackware 15              940  MiB
MX Linux 21               940  MiB
Redcore                 1,001  MiB
Mageia Cauldron         1,006  MiB
Manjaro                 1,031  MiB
KDE Neon (Jammy)        1,049  MiB
Arch                    1,059  MiB
Fedora 38               1,139  MiB
openSUSE Tumbleweed     1,210  MiB
Debian testing          1,211  MiB

A média de 17 segundos do boot até exibir o Painel do KDE não representa grande melhora em relação aos 18 segundos da média anterior — pois em Maio e Junho também houve 5 registros de 17 segundos — e apenas 2 casos puxaram a média um pouco para cima.

Quanto à redução do uso inicial de Memória RAM, pode ter sido causada por um ajuste mais rigoroso na desativação de serviços que não uso.

Enfim, mantive a data de instalação: Julho 2020 — porque, de fato, é a instalação que continuo usando — agora, como “Cauldron”.

Por que Cauldron

Fiz o upgrade do Mageia 8 (stable) para o Mageia Cauldron (testing) para me antecipar ao próximo lançamento do Mageia 9 — mas também para me livrar daquela rotina de instalar uma nova versão a cada 2 anos, com todo o trabalho de configurar repositórios, adicionar pacotes etc. — O upgrade preserva a maior parte do trabalho já realizado para adequar a distro ao que eu preciso.

Me acostumei às distros Linux de lançamento contínuo — 6½ anos com o Debian testing, 6 anos com o Arch, 5 anos com o PCLinuxOS, 4 anos com o openSUSE Tumbleweed e com o Void — e acabei perdendo o interesse por distros “estáveis”, ou de “lançamento fixo”, que ficam estagnadas durante 2 anos, e depois dão trabalho.

Nesse período, instalei o Mageia 6 sta2 (uns 4 meses antes do lançamento); o Mageia 7 beta2 (uns 3 meses antes do lançamento); e o Mageia 8 alpha1 (uns 6 meses antes do lançamento). — Portanto, lidei pelo menos 3 vezes com a fase final de desenvolvimento dessa distro; e nunca tive problemas com isso. — Havia muitas atualizações, pacotes sempre nas versões mais recentes. Quase um rolling-release! Mas após os lançamentos, as coisas estagnavam e perdiam a graça.

O que fiz agora foi evitar mais uma instalação — que neste momento, seria a do Mageia 9 beta2 — e várias outras, nos próximos anos.

E por que não via DNF?

Aviso para não misturar dnf e urpmi

Já fiz 8 upgrades do Fedora pelo dnf — do 30 para o 31, para o Fedora 32 — e não parei mais, até o Fedora 38 (por enquanto), sem nenhum problema.

De início, até achei que poderia ser mais cômodo fazer o upgrade do Mageia pelo dnf — mas vi que não é bom alternar o uso dele com o do urpmi.

Há motivos para não misturá-los.

A Wiki do Mageia é clara: — “URPMI e DNF usam métodos diferentes para rastrear órfãos. Se você usar os dois, nunca deve usar a funcionalidade automática de nenhum deles para remover órfãos”.

Enfim, já uso o dnf no Fedora — e no Mageia prefiro continuar explorando o urpmi.

___________________
• Publicado em 5 Julho 2023 e desenvolvido até 7 Agosto 2023.

— … ≠ “•” ≠ … —

PC desktop UEFI / GPT

Multi-boot de 12 distros Linux

noreply@blogger.com (Mboaba) — Thu, 15 Jun 2023 16:08:01 +0000

Quadro: - Situação das 12 distros instaladas até 11 Junho 2023

• Isto não é uma “comparação técnica” entre distribuições Linux — até porque nenhuma delas é uma “instalação padrão” (out of the box). — Isso é apenas um “quadro da situação” das minhas distros neste momento, às vésperas das novas versões do Mageia e do MX Linux.

Todas instaladas em dualboot (multiboot), por segurança. — Se uma distro quebrar, basta reiniciar, escolher outra, e continuar minhas atividades em 2 minutos; e conserto quando tiver tempo. — (O último desastre fatal foi em 2017, quando eu tinha 4 distros, 2 quebraram, e pude resolver com calma, semanas depois).

Me acostumei a mudar de “distro preferida”, a qualquer momento em que me sinta mais confortável com outra — um “distro-hopping em baixa velocidade”. — Se não consigo dominar uma distro logo no começo, continuo tentando nas horas vagas, durante meses, ou anos.

Tenho escolhido distros que cubram os “ramos” principais da “árvore de distros Linux” — diferentes filosofias, diferentes sistemas init, diferentes modos de instalação, de empacotamento e gerenciamento de pacotes etc. — para não ficar dependente de nenhuma empresa ou comunidade, em caso de falência, compra, venda, incorporação, mudanças drásticas, ou outra inconveniência.

Para lidar com essa “creche”, preciso lembrar as características das várias distros que tenho, anotar o que já consegui em cada uma, e o que ainda falta aprender. — O Quadro (acima) me ajuda a ter uma visão geral.

Os itens avaliados mudam com o tempo. — Hoje, quase não preciso do Wine; o corona-cli já não é tão necessário; e o speedtest-cli deixou de ser útil; mas ainda registro, até que outras tarefas tomem seus lugares. — Em 2017, minhas preocupações eram bem outras (Fevereiro, Junho).

2024 Agosto - Adicionei algumas observações sobre o que aconteceu desde a publicação original dessas notas — mas sem entrar em detalhes, pois isto exigiria reescrever quase tudo.

2024: eliminei 4 distros, para simplificar minha vida

2024 Dezembro - Eliminei 4 distros, nas quais perdi interesse: — KDE Neon, Slackware, Manjaro e Redcore. — Bastou carregar outra distro, desmontar suas partições-raiz e formatá-las (preservando as partições /home). — Por fim, atualizei o Grub para refletir a nova situação; e editei o arquivo de configuração do Conky. — Estou pensando em experimentar o Artix.

Índice

Visão geral

Label
Partições-raiz
Tipo de lançamento
Kernel
KDE Plasma
Software init
Servidor gráfico
DE Console
Sistema de arquivos
Empacotamento e gerenciadores de pacotes
User ID
Data da instalação
Espaço ocupado na partição-raiz
Tempo de boot
Uso de Memória RAM
GoogleEarth
Sincronização do Google
Foliate
corona-cli
yt-dlp
speedtest-cli
Wine
Outros itens

Grub
uDisks2
Weather
Exif
Pré-visualização de arquivos no Dolphin
Kim4

Mudanças nos aplicativos do KDE
Atalhos personalizados no Wayland
Gerenciadores de pacotes
Distros “preferidas”
Um passo de cada vez
Hardware

Visão geral

Mensagens de erro de Rede na inicialização de várias distros Linux

Label - Tanto as partições-raiz quanto os hostname's são numerados (Linux1 a Linux12), para facilitar minha vida no dia-a-dia. — Recebo mensagens de erro durante o boot de algumas distros, talvez por não aceitarem maiúsculas e números (ou talvez, por conflito entre systemd e /etc/hostname) — mas não há problemas de conexão.

Redistribuição das distros entre 2 SSDs Sata III

Partições-raiz - Em Maio 2023, instalei um segundo SSD Sata III e “movi” para ele metade das distros. — Com isso, deixei de usar HDD (Swap, partições /home, partições de documentos) — o que reduziu bastante o tempo de boot de todas as distros.

Distribuir 12 distros em 2 SSDs era minha intenção desde 2020, por uma questão de segurança — e só adiei devido à pandemia.

Tipo de lançamento - O Slackware permanece um desafio, para mim, e desisti de torná-lo “rolling-release” (current), por enquanto. Limito-me a atualizar um ou outro pacote, quando necessário. — O Redcore sofreu algum desastre, e agora também atualizo só um ou outro pacote; por isso, não classifico mais como “rolling-release”, até consertar. Reinstalar não me ensinaria nada, por isso prefiro continuar tentando. — Ambos funcionam bem, exceto por alguns pacotes que ainda faltam.

Kernel - Uso o Kernel que cada distro “traz naturalmente”, e desde 2007 isto só me incomodou 1 vez: — Instalei o Kernel corrente no Arch, e só quando se desentendeu com o Grub é que instalei o LTS, em Março 2023. — No Manjaro, optei pelo Kernel LTS desde a instalação (mas não é o mesmo Kernel LTS do Arch).

KDE Plasma - Todas as distros estão com o KDE — e procuro configurá-las tão “igual” quanto possível, de modo que mal percebo a diferença, ao passar de uma distro para outra. — No Mageia 8, no Slackware 15 e no MX Linux 21, ainda tenho alguns recursos que desapareceram em versões recentes dos aplicativos KDE. Nada que me incomode muito. (Ver “Mudanças nos Aplicativos do KDE”, adiante).

systemd-analize vs. disponibilidade efetiva do Plasma KDE

Software init - Apenas no Void, precisei lidar com o Runit, pois fiz a instalação básica e depois adicionei o Plasma KDE. Nenhuma dificuldade. Só não encontrei um comando para exibir sua versão. — Eu raramente uso comandos do SystemD — e nas outras distros, ainda não precisei lidar com o SysV nem com o OpenRC.

O único efeito prático, é que não disponho de uma ferramenta unificada (como o systemd-analyze) para medir com precisão o tempo de boot de todas as distros — mas isso talvez seja bom, pois de nada me serve receber números como 15’’, se o Painel do KDE só se torna disponível, de fato, aos 24’’ uptime:

«Note that these measurements simply measure the time passed up to the point where all system services have been spawned, but not necessarily until they fully finished initialization or the disk is idle»

Servidor gráfico - Só no Fedora, mudei do X11 para o Wayland, para ficar de olho no que promete se tornar o próximo padrão. — Por enquanto, precisei apenas substituir o gnome-screenshot pelo KDE Spectacle — ambos com salvamento automático (commandline in background), sem abrir janela de diálogo GUI. (Ver “Atalhos personalizados no Wayland”, adiante).

DE Console - Localização do ambiente Plasma KDE nos Consoles tty1, tty7 e até mesmo no tty8. — Informação inútil, já que é muito mais rápido tentar logo as 3 alternativas do que procurar “onde foi que anotei” — ao voltar do tty2, que é onde costumo executar comandos fora do ambiente gráfico do KDE.

2024 - Em várias distros, agora o KDE usa o tty2

Partição BtrFS quase “vazia”, vista a partir de outras distros

Sistema de arquivos - Somente no openSUSE, optei por partição-raiz em BtrFS (com snapshots). Nenhum problema com BtrFS, desde 2017 — mas isso dificulta localizar seus arquivos do sistema, a partir de uma sessão Live USB (ou a partir das outras distros). Para limitar essa dificuldade, mantive as outras distros em partições ext4. — Nenhum problema com a partição /home do openSUSE em XFS, desde 2017.

Empacotamento e gerenciadores de pacotes - O Arch, o Slackware e o Redcore têm modos próprios de empacotamento, que assinalei com asteriscos (*), na falta de outras siglas tão conhecidas quanto “deb” e “rpm” (aceito sugestões). — No openSUSE uso o zypper; no Fedora uso o dnf; no Mageia uso urpmi / urpme etc.; no Void uso xbps; no Redcore procuro usar o sysiphus (embora às vezes tenha de usar o emerge, para algumas tarefas). — No Debian, no KDE Neon e no MX Linux, uso o apt para verificar as atualizações; e o Synaptic para aplicá-las, ou para pesquisar e instalar novos pacotes. — No PCLinuxOS, uso só o Synaptic, para não me confundir com seu apt (apt-rpm). — No Arch, uso o pacman para atualizar o sistema; e só depois uso o yay para atualizar os poucos pacotes do AUR que utilizo. — No Manjaro, uso o pacman e, em seguida, o pamac-cli.

Minha primeira providência, ao instalar uma distro, é remover o PackageKit, responsável pela verificação automática de atualizações. — Deixei apenas no Mageia, que me ofereceu um modo rápido de “nunca verificar”; e no KDE Neon (também desativado), porque os desenvolvedores insistem que devemos usar o comando pkcon (uso pkcon nos upgrades de versão; e às vezes para verificar se o apt / Synaptic está fazendo tudo certo). — Ao remover o PackageKit, a “lojinha” Plasma-Discover também é removida, assim como o Apper do Debian.

Nas distros “deb”, também removo unattended-upgrades, que faz atualizações “de segurança” sem perguntar nem avisar — além de aumentar a fragmentação dos registros (log separado). — Prefiro fazer tudo pelo Synaptic, de modo a ter um Histórico centralizado (e fácil de pesquisar).

Portanto, nada se instala nem se atualiza, exceto quando eu comando manualmente, em geral aos Domingos — e não fico recebendo avisos impertinentes a toda hora.

Ainda não utilizo Flatpaks, Snaps, AppImages. — Utilizo o mínimo de repositórios não-oficiais de cada distro (Packman-Essentials no openSUSE, AUR no Arch, RPM Fusion no Fedora). — Em geral, habilito os repositórios do Google para o Chrome e o GoogleEarth, a serem usados pelo apt / Synaptic / dnf / urpmi / sysiphus etc., mas no Void e no Slackware a atualização precisa ser feita na unha. — No PCLinuxOS, o LibreOffice vem direto da fonte, por um aplicativo específico (não pelo Synaptic). — No KDE Neon, recorri apenas ao PPA do Foliate; mas um dos upgrades instalou automaticamente o PPA do Mozilla Firefox (que nem uso).

Enfim, em todas as distros, instalei o corona-cli pelo comando npm — vem do github, se não me engano. — Tentei o pip algumas vezes, no Arch, no Debian e no Slackware, sem muito sucesso.

User ID - Na minha primeira instalação do PCLinuxOS, o UID padrão era 500, e isso bloqueou o uso mútuo de arquivos com as demais distros, cujos usuários têm UID=1000. — Por isso, agora especifico UID=1000 ao reinstalar o PCLinuxOS. — Nunca tive problemas com GID=100, ou 1001, 1002 etc.

Data da instalação - No meu antigo PC, várias dessas distros foram instaladas a partir de Outubro 2016 (Debian testing) e de 2017 em diante, e continuaram funcionando sem grandes problemas até Janeiro 2020 — quando montei meu PC atual e optei por nova instalação das distros (agora, em UEFI-GPT). — As datas do PCLinuxOS e do MX Linux estão erradas, pois foram reinstalados em Agosto e Outubro 2021, respectivamente.

Em breve, será hora de decidir se vou reinstalar ou apenas fazer upgrade do Mageia e do MX Linux. — Nenhum problema com sucessivos upgrades do KDE Neon e do Fedora (ou do Leap, no antigo PC).

Espaço liberado após limpar o cache de pacotes baixados

Espaço ocupado na partição-raiz - Para o openSUSE Tumbleweed, destinei uma partição de 50 GiB, pois os “instantâneos” (snapshots) acumulam-se muito rápido. E limitei bastante o número de snapshots a serem mantidos. — Para as outras distros, destinei partições de 30 GiB — mas no caso do Redcore tive de ampliar para 60 GiB devido ao espaço exigido durante as compilações.

Nas distros em que uso o apt / Synaptic, configurei para sempre esvaziar o cache de pacotes baixados, após completar sua instalação. — No Arch, no Void e no Manjaro, faço uma limpeza do cache de pacotes baixados quando o espaço ocupado começa a aumentar muito. (Não costumo fazer downgrade de pacotes). — Enfim, o espaço ocupado também depende do número de pacotes instalados, quando a distro já vem com muita coisa, ou quando já adicionei muitos pacotes.

Average Boot Time (sec)

             Oct 2021   Jun 2023    Diff   Delta      Jan 2020

openSUSE         42’’       33’’     - 9    -22%          15’’
Arch             32’’       19’’     -13    -41%
Debian           23’’       17’’     - 6    -27%
Fedora           40’’       36’’     - 4    -10%          15’’
Neon             27’’       23’’     - 4    -15%          10’’
PCLinuxOS        25’’       18’’     - 7    -27%          16’’
Mageia           37’’       18’’     -19    -51%
Slackware        31’’       15’’     -16    -52%
Void             34’’       19’’     -15    -43%
Manjaro          31’’       19’’     -12    -40%
Redcore                     14’’
MX Linux         35’’       22’’     -13    -38%

Tempo de boot - Passo até 1 semana sem reiniciar o computador, por isso, ganhar alguns segundos no boot não é relevante — mas noto que o openSUSE (BtrFS + Snapshots) e o Fedora costumam demorar mais — enquanto o Debian testing e o KDE Neon demoram menos, por exemplo.

Após mover a partição Swap, as partições /home e as partições de documentos do HDD para SSDs Sata III, em Maio 2023, o tempo de boot diminuiu drasticamente (não tenho plano de investir em NMVe, no momento).

Os tempos acima são a média de várias observações (Conky), no momento em que finalmente é exibido o Painel do KDE Plasma. — Apenas no Debian, a montagem automática de 25 partições extras é feita pelo /etc/fstab — enquanto nas outras é feita pelo UDisks2, via KDE System Settings.

Esses tempos eram ainda menores em Janeiro 2020, quando eu ainda não usava partições Swap e /home; e a montagem automática envolvia apenas 3 ou 5 partições extras (todas em SSD Sata III).

RAM usage 10 min uptime (iddle) - just 1 sample

Void             878 MiB
PCLinuxOS        921 MiB
Slackware        940 MiB
MX Linux         940 MiB    --- average 967 MiB, for previous 6 samples
Redcore        1,001 MiB
Manjaro        1,031 MiB
Neon           1,049 MiB
Arch           1,059 MiB
Mageia         1,068 MiB
Fedora         1,139 MiB
openSUSE       1,210 MiB
Debian         1,211 MiB

Uso de Memória RAM - Com 16 GB de Memória RAM, não faz diferença se uma distro Linux usa 900 MiB ou 1.200 MiB ao terminar o boot e carregar a sessão Plasma KDE — mas talvez essas anotações possam ser úteis para quem tem um PC mais antigo / mais fraco:

Os números acima são de 1 única observação — exatamente aos 10 minutos uptime (iddle) — e vale lembrar que oscilam a cada segundo (e de um boot para outro)

Nenhuma dessas distros é uma “instalação padrão” (out of the box)

Todas, sem o KDE-PIM — KMail, KAddressBook, KOrganizer etc. — e portanto, sem 17+ processos do Akonadi em execução

Todas, sem File Search (indexação pelo baloo_file) — que nunca me fez falta para buscas simples no Dolphin (CTRL+F), ou avançadas (KFind). — Não uso Tags, Rating, Comment, Today, Yesterday etc. no Dolphin; e desativo os serviços correspondentes

Vários outros serviços de busca do KDE desabilitados: — Activities, Bookmarks, Browser History, Browser Tabs, Desktop Search, Dictionary, Locations, Places, Software Centre, Spell Checker, Web Search Keyords, por exemplo

Vários Background Services desabilitados em “Startup and Shutdown” — Bluetooth, KSysguard, Plasma Vault module, Remote URL Change Notifier, Search Folder Updater, SMB Watcher (em geral, também elimino o Samba, pois não tenho rede local).

Vários Desktop Effects desabilitados em Workspace Behavior

Todas as distros, sem verificação automática de atualizações e sem unattended-upgrades (atualizações silenciosas de segurança) — coisas que também aumentariam o uso inicial de RAM em várias distros

Apenas no openSUSE, serviços de manutenção BtrFS + Snapper

Apenas no Mageia, serviço MSEC (segurança) — mas sem verificação periódica de zilhões de arquivos em todas as partições

Apenas no Fedora, SELinux ativado. — Também veio no openSUSE, mas desabilitado

Afora os processos normais de cada distro, estão em execução apenas 2 instâncias do Conky — a segunda, executando comandos free, top, neoFetch, htop, inxi, Screenfetch, aha, html2text (em background) a cada 10 segundos — e os widgets Weather e Moon Phase, que aumentam em cerca de 45 MiB o uso de RAM

2024 - No Plasma 6, tive de remover o Moon Phase (by Gealach), que ainda não foi portado; e trocar o Weather2 por outras alternativas

Nenhum emulador de Terminal aberto — pois Konsole, XTerm, Xfce-Terminal etc. aumentam o uso de Memória, em quantidades diferentes, o que invalidaria a comparação entre distros com diferentes emuladores

A única ação executada durante os primeiros 10 minutos uptime é a captura de tela ao exibir o Painel do KDE — pelo Spectacle (no Fedora e no Slackware); ou pelo gnome-screenshot, — ambos por comandos (background: command), sem abrir diálogo em GUI

Aos 10 minutos uptime, um script agendado pelo crontab lê os dados em /proc/meminfo e registra o uso de Memória RAM em um arquivo TXT — usando um cálculo absolutamente igual, em todas as distros — ao contrário de ferramentas como free / top, htop, Neofetch, Screenfetch etc., que podem ter versões diferentes, com cálculos diferentes, de uma distro para outra

MEM_TOTAL=$(awk '/MemTotal/ { printf $2 }' /proc/meminfo); \
MEM_AVAIL=$(awk '/MemAvailable/ { printf $2 }' /proc/meminfo); \
MEM_USED_KILO="$(($MEM_TOTAL-$MEM_AVAIL))"; \
echo "$(($MEM_USED_KILO/1024))" MiB > MemInfo.txt

O cálculo executado por esse script (acima) é o que foi proposto por Linus Torvalds desde 2014: — Mem_Used = [Mem_Total - Mem_Available] — e que ainda não foi adotado por todas as ferramentas mais comuns.

Naturalmente, com Xfce, LXQt, Lumina ou um simples gerenciador de janelas — em vez do Plasma KDE — todas essas distros usariam muito menos Memória RAM

GoogleEarth - Não é fornecido diretamente por nenhuma dessas distros — mas pode ser instalado e atualizado pelos gerenciadores de pacotes de várias delas, a partir do repositório do Google (ou do AUR, no Arch). — No Mageia, abre e navega normalmente, mas a Busca (cidades, ruas) não está funcionando. — No PCLinuxOS, vários usuários conseguem instalar, mas nenhuma dessas dicas resolveu para mim. — No Slackware, no Void e no Redcore, o caminho é um pouco mais complicado, e ainda não consegui, ou ainda não tentei.

Sincronização do Google - Desde quando o Google bloqueou a sincronização do Chromium (e derivados), optei pelo Chrome, instalado e atualizado do mesmo modo que o GoogleEarth — porém, no Slackware, no Void e no Redcore é mais trabalhoso — e basta não estar 100% atualizado, para não sincronizar.

Foliate - Virei fã do ePub — e como não faz sentido salvar duplicatas de tudo em PDF, me tornei dependente do Foliate, rapidamente adotado pela maioria das distros. — Só no PCLinuxOS e no Slackware, ainda não instalei.

corona-cli - Instalei pelo comando npm — mas já faz algum tempo que não uso, e fui parando de atualizar (ele notifica novas versões, mas só quando é executado). — Ainda não instalei no Slackware e no Redcore.

yt-dlp - É o sucessor do Youtube-DL, que ficou abandonado. — Fundamental para baixar vídeos, também, do Twitter, do Facebook e outros mil lugares. — É um problema no KDE Neon, cuja base Buntu-LTS fica estagnada (e eu não uso PPA, Flatpak, Snapd etc.).

speedtest-cli - Já foi uma ferramenta fantástica... até a Ookla lançar seu próprio aplicativo — e impor limitações crescentes. — Os resultados deixaram de ser confiáveis (o que me obriga a usar o site da Ookla).

Wine - Já faz alguns anos que converti a maior parte dos meus DOCs dos anos 1990, usando velhas macros que criei no MS Word — e a maior parte dos Views DXF do AutoCAD, usando o CorelDraw. — Desde o início dos anos 2000, não criei para mim nenhuma nova “dependência” desses velhos softwares, e nas distros mais recentes nem cheguei a instalar o Wine. — Pelo que verifiquei esta semana, alguma coisa daquilo tudo ainda funciona no KDE Neon e no Fedora; ao passo que no openSUSE sumiu do Menu e talvez eu precise configurar de novo.

Outros itens

Entradas para Arch e Manjaro no Grub do openSUSE e do Mageia

Retirei do “Quadro” alguns itens que perderam importância — ou com os quais posso lidar sem necessidade de um lembrete permanente:

Grub - O Arch e o Manjaro exigem parâmetros, que só o Grub do openSUSE é capaz de detectar e incorporar, por padrão. — Para usar meu “Grub de reserva” (do Mageia), preciso fazer uma correção manual — caso a caso, conforme os Kernels do Arch e do Manjaro:

Find:           initrd /boot/intel-ucode.img
Replace with /  initrd /boot/intel-ucode.img /boot/initramfs-linux.img
    (or)     |  initrd /boot/intel-ucode.img /boot/initramfs-linux-lts.img
    (or)     \  initrd /boot/intel-ucode.img /boot/initramfs-5.10-x86_64.img

(Se eu remover o Manjaro e 1 dos 2 Kernels do Arch, bastaria uma busca-e-troca global automática no /boot/grub2/grub.cfg do Mageia — coisa que o editor do meu Midnight-Commander (mcedit) no Mageia já está treinado para fazer).

Por outro lado, o Grub do Mageia é o único capaz de detectar e carregar o openSUSE — instalado em partição BtrFS e sem /boot em partição separada. — Por isso, é o meu “Grub de reserva”.

Nas outras 10 distros, desabilito os-prober, para que o Grub deles não perca tempo detectando outras distros. — Basta que cada um detecte e gere entradas para sua própria distro — para serem lidas e incorporadas pelo Grub do openSUSE.

(Quanto mais distros os-prober tiver de verificar, maior a demora nas atualizações de algumas distros, ao instalarem novas versões / revisões de Kernel, pois executam os-prober 2 ou 3 vezes — em especial, quando também se remove a versão mais antiga).

Por isso, faço as atualizações em ordem inversa, do último (Linux12) para o primeiro (Linux1) — para que o Grub do openSUSE detecte e incorpore as atualizações de Kernel das outras 11 distros. — Considere isso um “algoritmo” a ser seguido, ao fazer dualboot / multiboot de distros Linux.

Enfim, no Fedora precisei desativar o Boot Loader Specification (BootLoaderSpec ou BLS), que impede a geração de “entradas” no seu próprio Grub, substituídas por “entradas” em /boot/loader/entries (que o Grub de outras distros não entende). — Por isso, o dnf não atualiza o Grub do Fedora, ao instalar e remover Kernels, e preciso atualizá-lo manualmente — caso contrário, o Grub do openSUSE (ou do Mageia) não verá novas “entradas” do Fedora para atualizar.

Montagem de partições extras pelo uDisks2, via KDE System Settings

uDisks2 - Apenas no Debian (Linux3), ainda uso o arquivo /etc/fstab para montagem automática das partições “extras” — ou seja, as que não são da própria distro, tais como “Warehouse”, “Sites”, “Works” e as partições das outras distros:

LABEL=Warehouse  /media/Warehouse   ext4        defaults,user    0   2
LABEL=Sites      /media/Sites       ext4        defaults,user    0   0
LABEL=Works      /media/Works       ext4        defaults,user    0   0
LABEL=Linux1     /media/Linux1      btrfs       defaults,user    0   0
LABEL=Linux2     /media/Linux2      ext4        defaults,user    0   0
# LABEL=Linux3     /media/Linux3      ext4        defaults,user    0   0
LABEL=Linux4     /media/Linux4      ext4        defaults,user    0   0
LABEL=Linux5     /media/Linux5      ext4        defaults,user    0   0
LABEL=Linux6     /media/Linux6      ext4        defaults,user    0   0
LABEL=Linux7     /media/Linux7      ext4        defaults,user    0   0
LABEL=Linux8     /media/Linux8      ext4        defaults,user    0   0
LABEL=Linux9     /media/Linux9      ext4        defaults,user    0   0
LABEL=Linux10    /media/Linux10     ext4        defaults,user    0   0
LABEL=Linux11    /media/Linux11     ext4        defaults,user    0   0
LABEL=Linux12    /media/Linux12     ext4        defaults,user    0   0
LABEL=Home1      /media/Home1       xfs         defaults,user    0   0
LABEL=Home2      /media/Home2       ext4        defaults,user    0   0
# LABEL=Home3      /media/Home3       ext4        defaults,user    0   0
LABEL=Home4      /media/Home4       ext4        defaults,user    0   0
LABEL=Home5      /media/Home5       ext4        defaults,user    0   0
LABEL=Home6      /media/Home6       ext4        defaults,user    0   0
LABEL=Home7      /media/Home7       ext4        defaults,user    0   0
LABEL=Home8      /media/Home8       ext4        defaults,user    0   0
LABEL=Home9      /media/Home9       ext4        defaults,user    0   0
LABEL=Home10     /media/Home10      ext4        defaults,user    0   0
LABEL=Home11     /media/Home11      ext4        defaults,user    0   0
LABEL=Home12     /media/Home12      ext4        defaults,user    0   0

Nas demais distros, uso o uDisks2 (via KDE System Settings); mas ainda enfrento falhas renitentes no Void e no Redcore, depois de reorganizar os discos (por exemplo, agora que “movi” partições dos HDDs para o novo SSD). — Isso exige montar manualmente (pelo Dolphin) as partições que faltam; e marcá-las outra vez para montagem automática.

Weather2 (widget), após o KDE 5.26

Weather - Uso esse widget desde 2016 (inicialmente, no KDE Neon), mas com a chegada do KDE 5.26, no último trimestre de 2022, começou a ficar truncado — exceto no MX Linux, Mageia e Slackware (ainda com KDE mais antigo). — A solução foi desinstalar o Weather (sem manutenção há 6 anos) e instalar o Weather2 (já na versão 2.33, de Outubro 2022).

Weather3 no Mageia Cauldron

2025 Março - Ainda não foi portado para o Plasma 6, no KDE Store — porém, no Mageia Cauldron, apareceu um Weather3 — já instalado, porque em 2020 eu tinha instalado um pacote “plasma-applet-weather-widget”. (Também tinha instalado esse pacote no Fedora, mas não foi atualizado para “Weather3”, até agora). — Investiguei, e encontrei no AUR um pacote “plasma6-applets-weather-widget-3-git”. — Não encontrei equivalente nas outras distros.

Dados Exif das fotos no Mageia Cauldron

Exif - No Redcore, ainda não consegui que o Dolphin mostre os dados Exif das fotos no Painel Informações (F11), do lado direito — embora o Gwenview tenha essa capacidade (ao custo de vários cliques).

Exibição de vídeos no Painel Informações (F11) do Dolphin

Pré-visualizações no Dolphin - De um modo geral, consegui (há alguns anos) que o Dolphin mostre pré-visualizações de arquivos de imagem, de vídeo, GIFs animados, TXT, ODT, ODS, PDF, ePub, Mobi, SVG, KML KMZ, XCF, e às vezes até DOC, DOCX, CBR (com direito a assistir os vídeos no Painel) — mas sempre há exceções de alguns tipos de arquivos, em alguma distro. — Não vale a pena registrar em detalhes, até porque isso varia ao longo do tempo.

Menu de contexto do Kim4 para o Dolphin, no MX Linux

Kim4 - Era um ótimo “menu de contexto”, desde os tempos do KDE4, para os recursos do ImageMagick no Dolphin — e ainda se encontra no AUR do Arch; e até recentemente, no repositório do MX Linux 21; enquanto o PCLinuxOS oferece um “Kim5”. — Isso deixou de ser relevante, desde que existem vários widgets com a mesma função, que podem ser baixados a partir das configurações do Dolphin.

2024 Dezembro - Isto se tornou um problema no Plasma 6, que ainda não resolvi.

Mudanças nos aplicativos do KDE

Antigos atalhos F10 e F11 no Kate / KWrite

Em algum momento, Kate / KWrite perderam as antigas teclas de atalho F10, para alternar “Dynamic Word Wrap” (on / off); e F11 para “Show Line Numbers” (on / off). — O F10 pode ser restabelecido manualmente, mas F11 agora conflita com o atalho global para “Full Screen”, e preferi não mexer nisso. — A solução foi tornar padrão “Show Line Numbers” (on) nas configurações, tanto do Kate quanto do KWrite, separadamente.

(No Dolphin, F11 ainda alterna on / off o “Painel Informações”, à direita).

O Gwenview agora “não pára“ no final de uma pasta. Avança... para o começo. Se eu optar por ser avisado, preciso de pelo menos 2 cliques para voltar. — Se eu ampliar e renomear (F2) um arquivo de imagem, não volta mais ao tamanho normal (Fit); e não atualiza o nome na barra de título da janela (o que impossibilita arrastar e soltar para upload). — Para atualizar o nome e voltar ao tamanho normal (Fit), torno a usar F2 + Esc em sequência.

Essas mudanças me incomodaram, porque uso esses recursos o tempo todo, tentando não perder tempo. — Para amenizar, alterei minha personalização do Gwenview (Barra de Ferramentas). — Ainda tenho os antigos comportamentos no Slackware 15, no Mageia 8 e no MX Linux 21, mas isso está perto de acabar.

Ok, há muitos anos a evolução permanente do Plasma KDE costuma aprontar incômodos como esses (e até piores) — mas no final das contas, vale a pena, diante do acréscimo de ótimas funcionalidades. — Lembro que muitos recursos foram perdidos na passagem do KDE4 para o KDE5, e depois voltaram aos poucos.

Lidar com essas perdas faz parte da minha opção inicial pelo KDE Neon, com Plasma sempre novo; e mais tarde, por distros rolling-release — ao invés de ficar 2 anos num Kubuntu LTS estagnado, e depois receber uma cambulhada de novidades — o que anula a “produtividade”, até que eu me acostume outra vez.

O Fedora KDE Wayland alterou várias coisas. — Agora, renomear um arquivo no Gwenview (F2) abre uma sub-janela no alto, à esquerda, em vez da janelinha centralizada de todas as outras distros com a mesma versão de KWin ou dos Aplicativos KDE em sessão X11.

Em suma, o Wayland eliminou a configuração autônoma da sub-janela pelo KWin.

Atalhos personalizados no Wayland

Criação de atalhos personalizados para o gnome-screenshot em Plasma X11

Há muitos anos, adotei o gnome-screenshot em “modo automático” (sem perguntas) para capturar telas ou janelas e salvar automaticamente em arquivos JPG com um padrão de nome “data + hora + sufixo da distro”:

PrtScn ----- Capture and save full screen
gnome-screenshot -p -f /PATH/$(date +%F_%H-%M-%S)_Xxx.jpg

Shift+PrtScn ----- Capture and save full screen after 7 seconds
gnome-screenshot -p -d 7 -f /PATH/$(date +%F_%H-%M-%S)_Xxx.jpg

CTRL+Shift+PrtScn ----- Capture and save active window
gnome-screenshot -w -p -f /PATH/$(date +%F_%H-%M-%S)_Xxx.jpg

CTRL+PrtScn ----- Capture and save active window after 7 seconds
gnome-screenshot -w -p -d 7 -f /PATH/$(date +%F_%H-%M-%S)_Xxx.jpg

Criação de atalhos personalizados para o KDE Spectacle em Plasma X11

Apenas no Slackware, eu ainda usava o KDE Spectacle, enquanto não encontro o gnome-screenshot para instalar — mas o diálogo GUI é muito incômodo, para fazer várias capturas com retardo. — Isso foi resolvido graças à dica de um colega sobre os comandos CLI, em Maio 2022:

PrtScn ----- Capture and save full screen
spectacle -p -b -o /PATH/$(date +%F_%H-%M-%S)_Xxx.jpg

Shift+PrtScn ----- Capture and save full screen after 7 seconds
spectacle -p -d 7000 -b -o /PATH/$(date +%F_%H-%M-%S)_Xxx.jpg

CTRL+Shift+PrtScn ----- Capture and save active window
spectacle -p -a -e -b -o /PATH/$(date +%F_%H-%M-%S)_Xxx.jpg

CTRL+PrtScn ----- Capture and save active window after 7 seconds
spectacle -p -d 7000 -a -e -b -o /PATH/$(date +%F_%H-%M-%S)_Xxx.jpg

Teste do KDE Spectacle por comandos no Fedora

A discussão, naquele momento, era devido ao gnome-screenshot não funcionar em sessão Plasma Wayland — e minha primeira providência foi adotar o KDE Spectacle para poder testar o Wayland no Fedora, de modo permanente.

Logo em seguida, o KDE System Settings eliminou a seção “Atalhos Personalizados”.

2024 - Isto ficou ainda mais complicado, quando chegou o Plasma 6 — mas surgiu (ou demorei a descobrir?) outro caminho para criar Atalhos Personalizados, no KDE System Settings. — Ao longo do 1º semestre de 2024, também houve pelo menos 2 mudanças nos códigos do KDE Spectacle para salvar os arquivos das capturas em formato “YYYY-MM-DD_HH-mm-SS”, e quando falha o código antigo, não recebo aviso. Apenas não salva; ou salva com nome errado, e portanto fora da sequência cronológica esperada.

Gerenciadores de pacotes

Downloads do pacman em ordem decrescente de tamanho dos pacotes

Usar vários gerenciadores de pacotes, lado a lado, todas as semanas, é uma das alegrias dessa vida — e não me canso de acompanhar os indicadores de velocidade de download, atividade de CPU, Disk I/O etc., pelo Conky.

O pacman é, sem dúvida, o mais interessante — por baixar os pacotes em ordem decrescente de tamanho, o que ajuda a manter uma velocidade ótima, já que cada requisição implica no início de uma nova remessa. — Para coroar, indica a velocidade de download de cada pacote; e a média do conjunto, no final.

O dnf, que uso só no Fedora, também tem o ótimo hábito de apresentar esses números (embora em MB, não em MiB) — mas a ordem dos pacotes é outra, o que implica em oscilações bruscas de velocidade. — E uma vez que se disponha de boa conexão, já não faz sentido o tempo gasto para calcular o “delta RPM” de cada pacote e do total de “economia de banda”.

2024 Outubro - O dnf abandonou essa perda de tempo com “delta RPM” . — Com o Fedora 41, o dnf5 introduziu mais algumas melhorias — mas quem preferir, ainda pode comandar “dnf4”.

Graças a essas estatísticas do pacman e do dnf, é fácil comparar a demora relativa dos downloads do zypper — sempre nos mesmos dias, com o mesmo hardware, e a mesma conexão.

A velocidade de download do zypper sempre foi apenas uma fração do que minha conexão permitia — quando eu tinha 10 “megas”, depois 200 “megas”, e agora 480 “megas”. — Contratar uma conexão mais rápida melhora, mas sempre obtenho só uma fração do obtido em outras distros, nos mesmos dias e horários.

Tanto no openSUSE quanto no Fedora, aceitei a configuração-padrão, que redireciona para espelhos mais “próximos” ou mais velozes (sem que eu saiba quais são) — mas no openSUSE o resultado é sempre muito menor. — Para comparar, no Arch eu uso um espelho fixo, ótimo no eixo Paraná-Brasília:

           openSUSE     Arch            Fedora

 4 Jun     6,6 MiB/s    33.7 MiB/s      22   MB/s
28 May     6.8 MiB/s    33,7 MiB/s      23   MB/s
21 May    10.3 MiB/s                    26   MB/s
 7 May   ~ 5   MiB/s                    19   MB/s

After "download.max_concurrent_connections = 10" in /etc/zypp/zypp.conf

18 Jun     3,3 MiB/s    29.1 MiB/s      18   MB/s
25 Jun     7.1 MiB/s    30.6 MiB/s      14   MB/s

O zypper também é menos cômodo para copiar e manter um registro em arquivo TXT (legível a partir de outras distros) — e o mesmo posso dizer do urpmi (no Mageia) e do xbps (no Void). — O urpmi não indica velocidades de download; e as velocidades que o xbps indica não conferem com o mostrado pelo “downspeed” do Conky.

Tamanho pré-definido do nala oculta listas mais extensas

Nas distros .deb, uso o apt apenas para “ver” se todos os repositórios respondem bem — e quantos (e quais) pacotes serão atualizados. — Experimentei o nala, mas o tamanho pré-definido de seu quadro restringe a visualização de listas mais extensas (talvez possa alterar isso, mas não descobri como). — Isso é chato, no caso do Debian testing, por exemplo, que chega a consultar mais de 100 arquivos nos repositórios, para definir quantas centenas de pacotes precisa baixar.

Resumo dos pacotes e total do download, no Synaptic

Após verificar, pelo apt, se todos os repositórios respondem, abro o Synaptic, clico em “Mark all upgrades” — e invisto um tempo a examinar as seções “Auto-removable”, “Local or obsolete”, “Residual config”, “Missing Recommended packages” etc. — Quando há nova versão ou revisão de Kernel, aproveito para procurar e marcar o mais antigo para remoção completa. — Ao clicar em “Apply”, registro o resumo dos pacotes a serem atualizados, instalados, e o tamanho do download.

Como não indica a velocidade de download, preciso medir a duração pelas capturas de tela do Conky + KRuler (1 pixel = 1 segundo) — e faço a conta. — Mas isso é trabalhoso, por isso, em geral, limito as comparações ao Pacman e ao dnf.

Pesquisa por “packagekit” no Histórico do Synaptic

O Synaptic é uma ferramenta excepcional, com todas as funções oferecidas pelo apt (e mais nada) para examinar a consistência do sistema, os pacotes de cada repositório, e assim por diante. — Nunca encontrei nada tão completo, nem no YaST2 (openSUSE), nem no Mageia, ou em qualquer outra distro. — O histórico do Synaptic permite localizar todas as atualizações, instalações, remoções de qualquer pacote (e alguma dependência que ficou).

Synaptic do PCLinuxOS, que usa o apt-rpm

No PCLinuxOS, não uso seus comandos apt (apt-rpm), para não me confundir com pequenas diferenças em relação ao apt das distros de base Debian — e seu Synaptic também apresenta algumas diferenças: — Se fizer 2 “Reloads” seguidos, esvazia-se a seção “New in repository”, o que é chato.

Distros “preferidas”

Já faz mais de 1 ano que uso o Arch Linux quase o tempo todo — embora eu tenha todos os recursos de que preciso, também, no openSUSE, no Debian, no Manjaro e no MX Linux. — Então, por que uso quase que só o Arch, em 99% do tempo, a semana inteira?

Talvez seja a distro que menos me dá trabalho — quase nenhum problema, nos últimos 6 anos — mas não tenho estatísticas objetivas.

Dizer que “fica fora do meu caminho”, talvez seja pouco. É muito mais do que apenas isso! — “Não tem sabor, não tem cheiro, não tem cor”, talvez seja a melhor definição. — A distro ideal é aquela que eu “não percebo qual estou usando”.

O Arch é uma das mais “enxutas”, por eu mesmo ter “construído” passo-a-passo: Só tem o que eu quis instalar. — Isso o torna “mais ágil”? Talvez seja apenas outra impressão subjetiva. Sem dúvida, a ausência de pacotes inúteis ajuda a atualizar mais rápido, mas o empacotamento, o pacman, o espelho (no Brasil) e a boa conexão até minha cidade também ajudam muito.

Tudo isso também vale para o Manjaro, exceto que nele tenho 1.429 pacotes instalados, mesmo sem Wine e outras coisas (contra 1.126 no Arch, com Wine + outras coisas), por ser uma instalação padronizada, não-pessoal; mas a diferença mal se percebe, no dia-a-dia. Apenas, o Manjaro não me atrai. — Instalei para testar e aprender mais algumas coisas (antes de aplicá-las no Arch); e mantive como uma “reserva de segurança”. Só que não sinto medo de perder o Arch, e eu não hesitaria em remover o Manjaro, se eu quisesse experimentar mais alguma distro.

Arch                             Manjaro

# pacman -Q --foreign            $ pamac list -m
google-chrome 114.0.5735.90-2    gnome-icon-theme          3.12.0-7          AUR  10.3 MB
google-earth-pro 7.3.6.9345-1    gnome-icon-theme-symbolic 3.12.0-6          AUR  2.0 MB
kim4 0.9.8-2                     google-chrome             114.0.5735.133-1  AUR  321.6 MB
pcurses 5-5                      google-earth-pro          7.3.6.9345-1      AUR  256.0 MB
ps_mem 3.14-2                    manjaro-documentation-en  20181009-1             10.0 MB
yay-git 12.0.5.r9.g1335e9b-1     manjaro-firmware          20160419-1             2.6 MB
                                 pcurses                   5-5               AUR  617.3 kB
                                 systemd-fsck-silent       239-1                  34.8 kB
                                 (+ kim4)                                    AUR

Acima: - Além dos pacotes oficiais, tenho apenas estes, no Arch e no Manjaro.

2024 Agosto - Mais tarde, esse tipo de estatística se embaralhou — porque instalei uma penca de “alternativas ao Neofetch” (além de Nerd Fonts), no Arch, mas não no Manjaro. — E exagerei no Void, com centenas de Nerd Fonts, ao ponto de torná-lo uma distro entulhada, ou bloated.

O Debian testing e o MX Linux também me atendem perfeitamente — com a diferença de que o Debian traz uma quantidade enorme de pacotes que não uso (por exemplo, o LibreOffice trouxe todos os idiomas do Universo); e isso contribui para tornar mais demoradas as suas atualizações (além do seu empacotamento fragmentado). — O MX Linux desempenha as mesmas tarefas, com muito menos pacotes (2.513, contra 3.638 do Debian); e por ser “stable”, costuma ter pouquíssimas atualizações; porém, traz uma ótima coleção de aplicativos muito úteis (e em versões bem recentes), que o Debian “stable” não ofereceria.

É possível fazer uma instalação enxuta do Debian, mas não vejo motivo para tentar isso, por enquanto. — Ele me atende bem, tal como está.

Importante: - O número de pacotes do Debian / MX Linux não pode ser comparado com o do Arch / Manjaro, por se tratar de sistemas de empacotamento muito diferentes.

Outra distro que me atende perfeitamente é o openSUSE Tumbleweed — apesar de também ter um excesso de pacotes, de que não preciso, só porque aceitei os “patterns”. — Também é possível fazer uma instalação bem mais “enxuta”, mas isso é outra coisa que não me disponho a tentar, no momento: Seria muito trabalho, para pouco benefício.

Com todo possível “inchaço”, o openSUSE tem funcionado com precisão, nos últimos 6 anos e meio — através de vários upgrades de versão do Leap; e em seguida para Tumbleweed (no meu antigo PC). — Continua sólido no meu PC atual, com poucos pacotes do repositório packman-essentials (e do Google).

Tenho encontrado a mesma solidez no Fedora e no KDE Neon, através de sucessivos upgrades de versão — mas não me atendem tão completamente.

2024 Agosto - Tudo isso se alterou bastante, com a chegada do Plasma 6. — Hoje, é comum eu clicar para abrir algum aplicativo no openSUSE Tumbleweed, demorar a abrir, e acabar não abrindo. — E no KDE Neon com Plasma 6 (instalação nova), ainda não consegui muitas coisas que tenho na instalação antiga, com Plasma 5.

Independente de tudo isso, gosto de usar o Void, o Redcore e o Slackware. — Funcionam maravilhosamente (exceto pelo que me falta aprender e obter). — Verdadeiros docinhos-de-côco.

Um passo de cada vez

Uma “regra” fundamental que tento seguir (já que tenho 12 distros em dualboot para escolher), é “não forçar a mão”, nem recorrer a soluções “fáceis” porém duvidosas, por “necessidade de urgência”. — Já que o Arch me atende do modo tão completo, posso deixar “de molho” por semanas, meses!, qualquer problema que surja nas outras distros. — Sinto-me à vontade para gastar tempo em busca de soluções “limpas”, em vez de ceder a qualquer tipo de gambiarra improvisada.

Não é, só, que eu seja um “cara enjoado” (de fato, sou). — Mas tentar fazer as coisas com calma, um passo de cada vez, ajuda muito a ter mais certeza das coisas, em vez de apenas “achar que entendi”. — Posso experimentar várias hipóteses (sem embaralhar!), uma por uma, de modo a ter razoável certeza de qual suposta solução estava errada, e de qual realmente foi a resposta certa.

O que mais evito, é tentar meia-dúzia de coisas, uma após outra (sem desfazer uma, antes de tentar outra!) — porque desse jeito, no final é impossível afirmar qual tentativa ajudou (ou impediu) que a outra desse resultado. — É fundamental testar 1 variável de cada vez, pois quando se mexe em 3 ou 10 variáveis, ninguém pode concluir nada, sobre qual delas fez diferença, por si só, ou em conjunto com (quais?) outras.

Quando se embaralham variáveis, qualquer “conclusão” não passa de exercício do “é isso, porque minha intuição garante” — ou, pior, “é isso, porque eu sei, com base na minha sapiência”. — É melhor duvidar (sempre!) de nós mesmos, seguir um roteiro “impresso e auditável”, e apresentar todos os dados para que qualquer pessoa (contra ou a favor) tenha condições de repetir o experimento e informar à comunidade se deu certo ou não, em seu hardware, SO etc., bem especificado.

Em resumo: — Minhas conclusões podem estar erradas. — Por isso, procuro mostrar os elementos que recolhi, para qualquer colega poder verificar.

Hardware

Meu hardware ainda é o que montei em Janeiro 2020 — com alteração apenas dos dispositivos de armazenamento.

Em Maio 2023, instalei um 2º SSD de 480 GB (447 GiB) — e mais tarde desconectei os 2 HDDs de 1 TB (931 GiB) — que agora ficam em “gavetas” externas USB 3.0, para uso ocasional:

      Mobo: TUF B360M-PLUS GAMING/BR, BIOS 2401 03/22/2019 - ASUSTeK
      iGPU: Intel Corporation UHD Graphics 630 (Desktop)
Processors: 6 × Intel® Core™ i5-9400 CPU @ 2.90GHz (min / max: 800 ~ 4100 MHz)
    Memory: 15.5 GiB of RAM

Local Storage:             total: 894 GiB                 used: 251 GiB   (28.1%)

Sata #1   /dev/sda   SSD   Sata III   Kingston   SA400S37480G   447 GiB   probably 2019
Sata #2   /dev/sdb   SSD   Sata III   WD         WD Green 2.5   447 GiB   2022

External Storage:

USB 3.0 / 5 Gb/s     HDD   Sata III   Seagate    ST1000DM010    931 GiB   probably 2021
USB 3.0 / 6 Gb/s     HDD   Sata III   Seagate    ST1000DM003    931 GiB   2016

USB 2.0              SSD   USB 2.0    Samsung    S2 Portable    931 GiB   2011

Quando digo “mover” partições é, na verdade, copiar & colar (pelo GParted ou pelo KDE Partition Manager) — testar as cópias — e deletar os originais.

Fiz isso de 1º a 3 Maio 2023:

Copiei as partições Linux7 ~ Linux12 do 1º SSD (sda) para o 2º (sdb).

Copiei as partições Home7 ~ Home12, de um HDD para sdb.

Mudei os rótulos das partições originais para Linux7old ~ Home12old e alterei seus identificadores UUID — para testar o funcionamento das cópias em sdb, com os rótulos e UUIDs originais.

Após testar estas 6 distros em sua nova localização, deletei as partições originais Linux7old ~ Home12old.

Copiei as partições Home1 ~ Home6 do HDD para sda — alterei os rótulos e identificadores UUID das partições originais — e testei estas 6 distros com as cópias de suas partições /home, antes de deletar os originais.

Copiei a partição Swap do HDD para sda. — O GParted manteve o UUID na cópia, o que dispensou alterar 12 arquivos /etc/fstab.

Renomeei as antigas partições de documentos com “_X” para preservar seus arquivos

Três semanas depois, desconectei os 2 HDDs de 1 TB — um com 3 partições de documentos (Warehouse, Works, Sites) — e o outro, com a partição “Depot1”, onde faço os backups e guardo arquivos pouco acessados.

Em sdb, criei uma nova partição “Warehouse”, para os documentos de uso corrente a partir de agora — e copiei só o essencial da partição antiga.

Em sda, criei pequenas partições “Sites” e “Works” (2 GiB, cada), apenas para manter as configurações do Conky, do uDisks2, dos arquivos fstab, do rsync etc. — Ficam 140 GiB não-usados em sda.

Pastas renomeadas, para não serem esvaziadas pelos próximos backups

Renomeei os rótulos das partições antigas para “Warehouse_X”, “Works_X”, “Sites_X” — e também seus backups em “Depot1” e “Depot2” — para não serem esvaziados, ao fazer o backup semanal das novas partições.

Observações:

Para desmontar e lidar com as partições nº 1 ~ 6, usei uma distro do “2º grupo” (nº 7 ~ 12) — e vice-versa.

Para copiar a partição /home do openSUSE, em sistema de arquivos XFS, usei o KDE Partition Manager do MX Linux (pois o GParted não faz isso). — A cópia já veio com um novo UUID, e tive de editar o /etc/fstab do openSUSE. — Testei 2 vezes o funcionamento do openSUSE com a sua /home em novo local, com novo UUID.

No Slackware, uso o caminho (PATH) das partições de sistema no /etc/fstab — por isso, tive de alterar a raiz “/” para sdb2, a /home para sdb8 e o Swap para sda13. — Não é uma boa prática, pois às vezes sda e sdb podem se inverter; mas felizmente isso nunca me aconteceu com o Slackware (o mais comum é acontecer com o Redcore).

xxx

— … ≠ “•” ≠ … —

PC desktop UEFI / GPT

Ferramentas &tc.

Conky - monitor do sistema

Grub enlouquecido com 12 distros em multiboot

Remanejamento de sistemas Linux ao reparticionar discos

Backup total e limpeza das partições de trabalho
Migrando sistemas Linux para disco rígido de 1 Terabyte
Ensaio de avaliação com luckyBackup e Unison
Particionamento de Drive SSD para vários Linux

Quantas pessoas cabem na Esplanada dos Ministérios?

noreply@blogger.com (Mboaba) — Sat, 05 Nov 2022 20:00:02 +0000

Esplanada e suas pistas norte (N1) e sul (S1), da L2 à Alameda
(2004, ainda sem o Museu e a Biblioteca Nacional, junto à via S1)

Cerca de 200 mil pessoas teriam participado da 1ª posse de Lula, em 2003, segundo noticiaram, então, a revista Época (grupo Globo) e o jornal O Estado de S. Paulo, atribuindo esse número à PM-DF, que há décadas realiza a avaliação “oficial” de multidões em Brasília. — A Folha de S. Paulo atribuiu à PM-DF uma avaliação de 150 mil pessoas — e O Globo atribuiu à PM-DF uma avaliação de 70 mil pessoas.

Segundo levantamento posterior, da plataforma “Aos Fatos”, a PM-DF teria divulgado números progressivos, em 2003: — primeiro, 70 mil — depois, 150 mil — e só a revista Época teria “destoado”.

Porém, segundo o Estadão (2 Jan 2003, pág. H19), a PM-DF teria dado uma explicação, não “cronológica”, mas “qualitativa”: — “mais de 200 mil” pessoas compareceram, mas só 70 mil “participaram mais diretamente da festa” — seja lá o que isto pretenda significar.

Apenas 3 semanas depois, a Folha de S. Paulo encomendou uma revisão com base em fotos aéreas selecionadas — e reduziu seu número para 71 mil pessoas.

Questionada pela plataforma “Aos Fatos”, em 2019, a PM-DF deu 2 repostas diferentes: — Primeiro, que não tinha mais aqueles números de 2003, nem fotos, nem nada. — Depois, voltou atrás e afirmou que o “número oficial” era 70 mil.

Vivia-se, em 2019, uma situação inusitada: — “Decidiu-se” que a PM-DF não avaliaria a multidão presente à posse de Bolsonaro — e o único “número” fornecido foi o do GSI, já sob controle de seus aliados.

Bastou o GSI avaliar “115 mil pessoas” na posse de Bolsonaro, para superar as 71 mil “revisadas” da 1ª posse de Lula — o que levou o assunto para a mitologia.

Na 3ª posse de Lula, em 2023, o site G1 / Globo deu em manchete a presença de “centenas de milhares” — plural que pressupõe, pelo menos, 200 mil — enquanto a BBC optou por cautelosas “dezenas de milhares”; e afirmou que a PM-DF não divulgou números, pois “deixou de fazer esse tipo de estimativa já há alguns anos”.

No dia seguinte, 2 Jan 2023, o site Poder360 publicou sua própria estimativa, de 160 mil pessoas (“150 mil a 170 mil”) — com fotos aéreas, medidas do terreno via GoogleEarth — e frisou que isto supera as “100 mil a 115 mil” estimadas, também pelo Poder360 (e com a mesma metodologia), para o 7 Setembro 2022.

Estas são as únicas avaliações mais ou menos “comparáveis”, e mais ou menos “verificáveis”, que encontrei (até agora): — a da Defesa Civil DF / Folha de S. Paulo para a posse de Lula em 2003 (veja o PDF do jornal impresso, em “Referências”, adiante, pois a matéria online omite gráficos e fotos); — e as do site Poder360 para o 7 Setembro 2022; e para a posse de Lula em 2023.

Essas 3 avaliações seguiram “quase” a mesma metodologia (em 2003 não se verificou a densidade do público ao nível do solo) — por isso são as únicas que podem ser comparadas. — Mesmo assim, convém examiná-las com senso crítico:

2003     1ª posse de Lula      71 mil     Defesa Civil / Folha
2022     Sete de Setembro    ~108 mil     Poder360
2023     3ª posse de Lula    ~160 mil     Poder360

Hoje, as ferramentas para uma verificação estão acessíveis a todos:

Vídeos de 2003, 2019 e 2023 oferecem imagens bem documentadas — e fáceis de comparar, já que o cerimonial de posse segue os mesmos passos — cobrindo esses 3 eventos, de minuto a minuto.

O GoogleEarth — o GE Web ou o GE Desktop — permite medir as áreas ocupadas, na sequência das imagens.

Feito isso, resta avaliar a densidade da multidão — “quantas pessoas por metro quadrado” — em cada área, e em cada momento.

A avaliação “ao nível do solo” é o ponto mais fraco — subjetivo (pois não se imaginam equipes medindo o chão com trenas, no meio da multidão); portanto, não-verificável. — Só um conjunto completo de fotos 100% verticais, cobrindo todas as áreas, de hora em hora, permitiria a verificação do cálculo por terceiros.

Para não entrar em micro-detalhamentos, considero que 1 pessoa / m² tende mais a superestimar do que a subestimar as multidões dos últimos 20 anos — fartamente documentadas, desde a popularização da internet, das câmeras digitais e, agora, dos drones. — Em espaços tão amplos, por que iriam as pessoas se acotovelar, como se estivessem em um ônibus lotado, ou em um elevador apertado?

O que é a “Esplanada”, para que se possa medir?

Índice

Esplanada, Congresso e Três Poderes
Outras áreas
Acessos à Esplanada
Posse presidencial (I) - da Catedral ao Congresso

2003
2019
2023

Posse presidencial (II) - gramado do Congresso

2003
2019
2023

Posse presidencial (III) - Praça dos Três Poderes

2003
2019
2023

Posse presidencial (IV) - gramado da Esplanada

2003
2023

A guerra dos números (I)
A guerra dos números (II)
O tempo não para
Referências

Vídeos

Ferramentas

Esplanada, Congresso e Três Poderes

Largura e extensão do canteiro central da Esplanada dos Ministérios e vias N1 e S1

A área do canteiro central da Esplanada (nº 3 a 6) é de 200.000 m² — o equivalente a 20 hectares — ou 18,5 campos de futebol:

1.000 metros de extensão plana (ininterrupta), da via L2 até a Alameda de acesso ao Congresso Nacional — que é um caso à parte

200 metros de largura do canteiro central — de meio-fio a meio-fio — o que pode ser reduzido por eventuais barreiras

Canteiros centrais da Esplanada, da Rodoviária à Praça dos Três Poderes

Para um cálculo das áreas parciais — numeração inventada por mim:

Canteiro nº 3    100 m × 200 m  =   20.000 m²
Canteiro nº 4    380 m × 200 m  =   76.000 m²
Canteiro nº 5    400 m × 200 m  =   80.000 m²
Canteiro nº 6     75 m × 200 m  =   15.000 m²
    -----  via  L2   -----
Canteiro nº 7     75 m × 200 m  =   15.000 m²
Canteiro nº 8    385 m × 200 m  =   77.000 m²
    ----------------------
Via N1         1.000 m ×  20 m  =   20.000 m²
Via S1         1.000 m ×  20 m  =   20.000 m²

As pistas N1 e S1 têm 20 metros de largura — o que dá 20.000 metros quadrados (cada), só da L2 até a Alameda dos Estados — porém é rara a ocupação simultânea do canteiro central + via N1 + via S1:

Em um show, festa, comício, as pessoas se aglomeram no canteiro central

Em uma passeata, as pessoas se concentram em uma das pistas — ou em meia-pista, nos dias úteis

Para assistir a um desfile, as pessoas se aglomeram perto do meio-fio, dos 2 lados da pista — ou só de um lado, se houver bloqueio do outro

Além disso, a ocupação das vias N1 ou S1 costuma ser dinâmica. — A marcha pode começar no Ginásio Nilson Nelson (a 3 km) ou entre a Biblioteca Nacional e o Museu da República (junto à L2) — e é preciso verificar a extensão efetivamente ocupada, bem como a densidade em cada trecho, a cada momento.

Alameda dos Estados e gramado do Congresso Nacional

O Congresso Nacional tem certa “soberania” sobre seu gramado frontal, com uma extensão média de +/- 160 metros, da Alameda dos Estados até os espelhos d’água — e largura de 170 metros com inclinação suave, na parte central — ou 200 metros, incluindo as laterais mais íngremes e as faixas planas junto às vias N1 e S1.

Variações do gramado do Congresso Nacional

A área ocupada pode ser, portanto, de 27.000 m² — ou de até 32.000 m² — mas é improvável que uma multidão mantenha a densidade de 1 pessoa / m² nas laterais mais íngremes.

Das áreas próximas, só se aproveitam as beiradas, pois quem fica alguns passos atrás já não vê o que se passa nesse “anfiteatro”.

Praça dos Três Poderes

A Praça dos Três Poderes tem cerca de 30.000 m² — considerando as barreiras móveis que isolam o Supremo Tribunal Federal (STF), há alguns anos.

Descida da S1, da Esplanada para os Três Poderes, e barreiras do STF

Seria trabalhoso descontar pequenos espaços dentro da Praça — como a base do Museu Histórico, o acesso ao Espaço Lúcio Costa, o Centro de Turismo (antiga Casa de Chá) — e algumas estruturas eventuais, erguidas de ocasião.

Áreas verdes do Congresso junto à praça dos Três Poderes

Existem áreas próximas, como as palmeiras da Câmara, um gramado junto ao espelho d’água, e o bosque do Senado, que oferecem algum espaço — mas nem todas “aparecem na foto”, ou não oferecem boa visão da rampa e do Parlatório do Palácio do Planalto, por exemplo. — E nem sempre são permitidas.

Gramados junto à Praça dos Três Poderes

No cálculo acima, deixei de lado as palmeiras da Câmara (eventualmente ocupadas pelos Dragões da Independência), porque não são bom local para ver a rampa e o Parlatório do Palácio do Planalto. — A tendência é esta área de 6.700 m² ser ocupada em menos da metade, junto ao meio-fio — quando permitido.

Bloqueio na Praça dos Três Poderes diante do Palácio do Planalto, em 2003

Em alguns casos, barreiras temporárias isolam uma área considerável, junto à via N1, diante do Palácio do Planalto — como em Agosto 2003 — o que reduz a área ocupável para algo próximo a 25.000 m².

Para o cálculo dessas áreas parciais — números máximos:

Gramado do Congresso      160 m × 200 m  =   32.000 m²
Praça dos Três Poderes    140 m × 210 m  =   29.400 m²
Gramados junto à Praça                        6.700 m²

Outras áreas

Calçadão sombreado por árvores ao longo dos ministérios

Excluí do cálculo o gramado e o calçadão ao lado dos ministérios — única área mais sombreada, com grandes árvores — pois só são ocupados para assistir a algum desfile em uma das pistas (N1 ou S1).

Neste caso, a soma das multidões dos 2 lados dificilmente ultrapassa a que caberia na própria pista (20 metros de largura) — pois quem fica 10 metros atrás do meio-fio já não consegue ver quase nada.

Estacionamentos e Anexos dos ministérios, junto à via N2 (em nível inferior)

Também excluí do cálculo os estacionamentos “entre” os ministérios e “atrás“ deles, pois não têm significado em qualquer manifestação. — Quem fica ali, não vê, não é visto, não participa, não se manifesta. — Aliás, são áreas em geral ocupadas pela PM, como base de operações, agentes dos ministérios (e alguns seres misteriosos, como em 2017).

Esses estacionamentos “atrás“ dos ministérios ocupam o “teto” de suas garagens subterrâneas — servidas em nível inferior pelas vias N2 e S2.

Acessos à Esplanada

Limites do terrapleno da Esplanada e Praça dos Três Poderes

Todas essas áreas fazem parte de um terrapleno (aterro artificial), delimitado por quedas verticais de 3 a 8 metros em todo seu perímetro — com exceção da via L2, delimitada por rampas gramadas, bastante íngremes.

Desnível (muro) entre a Praça dos Três Poderes e o estacionamento inferior

A Praça dos Três Poderes fica em um terrapleno inferior ao da Esplanada — por isso, o desnível em relação ao “bosque da bandeira” é um muro de contenção do aterro, de “apenas” 3 metros de altura (1.058 m - 1.055 m altitude, segundo GoogleEarth Web). — Pode até parecer pouco, mas é melhor não pular.

E não se anime com a palavra “estacionamento”, pois nos grandes eventos todas as vias próximas são fechadas.

Limite vertical do terrapleno da Esplanada, atrás da Catedral (via S2)

O desnível é bem maior na Esplanada, propriamente dita: — 7 metros (1.981 m - 1.074 m) entre a Catedral e a via S2, que dá acesso às garagens e Anexos da Cúria Metropolitana, dos ministérios, Câmara, STF, PGR, TCU etc. do lado sul.

Escada para o desnível entre a Esplanada e a via N2, rebaixada

Em alguns locais, existem escadas para o desnível entre a Esplanada dos Ministérios e as vias inferiores N2 / S2 — mas não atenderiam a grandes multidões.

Em 2023, foram vedadas por tapumes, para não deixar dúvidas.

Rampa para automóveis entre a Esplanada e a via inferior S2

A maioria dos ministérios têm alguma rampa para veículos entre o terrapleno (Esplanada) e as vias rebaixadas N2 / S2 — algumas, privativas — e as outras, bloqueadas nos dias de grandes eventos.

Subida da via N1 para a Praça dos Três Poderes

Em dias comuns, pode-se chegar aos Três Poderes pela via N1, do Leste — mas em dias de grandes eventos esse trecho é bloqueado desde a Avenida das Nações — e não seria prático tentar a pé (se permitido), pois há pouco transporte público para se chegar à Orla do Lago (clubes, embaixadas, Vila Planalto).

Rampa gramada na passagem inferior da via L2

Só a Oeste, o terrapleno da Esplanada é limitado por uma rampa gramada, bastante íngreme (1.080 m - 1.075 m de altitude = 5 metros). — A rapaziada talvez ache bonito descer e subir por ali — mas não é prático para milhares de pessoas.

Restam, portanto, apenas 2 acessos à Esplanada dos Ministérios — os viadutos das vias N1 e S1 sobre a via L2 — a serem alcançados a pé, desde a Rodoviária (servida por linhas regulares de ônibus, Metrô, estacionamentos), em uma caminhada de mais de 700 metros.

Vir de outros setores próximos (Bancário, de Autarquias) implica em caminhadas maiores, com subidas e descidas — para chegar a esses mesmos 2 pontos.

Barreira e revista em bolsas e mochilas no viaduto N1 sobre a L2 em 2017

São os pontos naturais para revista no conteúdo de bolsas e mochilas — embora também possa haver outros bloqueios — próximos à Rodoviária, por exemplo.

Posse presidencial (I) - da Catedral ao Congresso

Público se fechando em torno do Rolls-Royce (O Globo, 2 Jan 2003)

Alguns vídeos com roteiro quase igual permitem uma comparação razoável das multidões nas posses de 2003, 2019 e 2023 — que qualquer um pode conferir, sem depender de “avaliações” com palavreado técnico-abstrato:

V1 (baixa resolução) - Vídeo de 3 horas 12 minutos da Rede Globo, cobrindo a 1º posse de Lula (2003), da Catedral até a passagem da faixa presidencial, no Parlatório do Palácio do Planalto. — Não inclui o show dos artistas (ao meio-dia), o discurso no Parlatório (no final da tarde), nem o desfile posterior no gramado da Esplanada.

V3 (baixa resolução) - Vídeo de 32 minutos do SBT, com a parte final da 1ª posse de Lula (2003) — do final do discurso no Parlatório até o desfile em zig-zag pelo gramado da Esplanada. — Começa por volta das 18:20 (Horário de Verão).

V2 - Vídeo de 2 horas 49 minutos da TV Senado, cobrindo a posse de Bolsonaro (2019), da Catedral até o Palácio do Planalto — inclusive passagem da faixa presidencial e discurso no Parlatório.

V4 - Vídeo de 11 horas 54 minutos do canal Lula no Youtube, cobrindo os eventos desde 12:40, quase 2 horas antes da chegada de Lula à Catedral, até 0:34 da madrugada — incluindo a aparição de Lula no Festival do Futuro, por volta das 23:00.

V5 - Vídeo de 9 horas 55 minutos da TV Senado, cobrindo desde a chegada de Lula e Alckmin à Catedral, até o discurso no Parlatório e a cerimônia interna no Planalto — com a hora de Brasília (BRT) sempre na tela, a partir das 12:30.

(As imagens são geradas por um pool de emissoras, e cada uma pode cortar / alternar entre várias câmeras, e adicionar câmeras próprias. — A diferença de resolução deve-se à transição da TV analógica para a TV digital, financiada pelo BNDES ao longo dos governos Lula e Dilma. — Horário de Verão em 2003 e 2019; horário “normal” em 2023).

2003

(V1: 5 min) - Público aglomerado próximo à Catedral, em 2003

O primeiro vídeo (V1, acima) começa com a multidão concentrada nas proximidades da Catedral — onde Lula entraria no Rolls Royce, para se deslocar até o Congresso Nacional — e ao longo da via S1, para acompanhar o trajeto.

A aglomeração não seguia nenhum desenho regular. Havia pessoas dos 2 lados da via S1, desde muito antes da Catedral. — No viaduto sobre a L2, a multidão invadia a pista dos 2 lados, por falta de espaço nas calçadas estreitas.

À medida em que o carro avança, a multidão se fecha em torno dele — obrigando à retirada dos Dragões da Independência — e chega a ocupar a via S1 por quase 1 km, atrás do Rolls-Royce.

(V1: 18 min)- Deslocamento da multidão com o Rolls Royce presidencial

Quando o Rolls Royce entrou na Alameda dos Estados, a maior parte da multidão já ocupava a via S1, ao longo do trajeto percorrido. — Outra aglomeração ocupava um triângulo do canteiro central nº 3, junto à Alameda — enquanto o gramado do Congresso ainda estava praticamente vazio.

2019

(V2: 4m ~ 4m 30s) - Pequeno público a 50 metros, atrás de tapumes e barreiras

As câmeras da TV Senado não registraram público perto da Catedral, para ver a partida do Rolls Royce com Bolsonaro.

O público só podia se mover pelo canteiro central, vedado por tapumes — e mesmo ali, foi mantido à distância da via S1.

Muitos optaram por olhar da Rodoviária (Foto: Bianca Marinho / TV Globo; sem a hora)

A imprensa registrou que “muitas pessoas” preferiram acompanhar o desfile de longe, do alto da Rodoviária — a 1 km da Catedral, ou a 2 km do Congresso — e sem nenhuma visão da Praça dos Três Poderes.

(V2: 6m 11s) - Aproximação à pista, só a partir do primeiro ministério

Só na altura do primeiro ministério, terminavam os tapumes e o público podia se aproximar da via S1 (mas não do meio-fio). — É a partir desse ponto que se vê alguma aglomeração — só do lado do gramado.

(V2: 6m 42s) - Aglomeração no retângulo nº 3

No restante da Esplanada, nota-se um início de aglomeração no canteiro nº 3 — que mais tarde será reforçada pelos que estiveram ao longo do percurso.

O cercadinho ao norte do gramado do Congresso ainda estava vazio. — Não tenho indicações de como foi a admissão dos que se movimentaram para lá em seguida, pois teriam de atravessar a Alameda dos Estados.

2023

(V4: 1h 51min) - Multidão na Esplanada, no desfile da Catedral ao Congresso

14:31 - Uma vista aérea do desfile em carro aberto entre a Catedral e o Congresso mostra a multidão nos canteiros centrais nº 4 (palco, ao fundo) — e nº 5 (Praça de Alimentação, fora da imagem), na 3ª posse de Lula.

Uma parte desse público se concentrava ao longo da via S1 — enquanto o restante se concentrava diante dos telões distribuídos dos dois lados centrais do gramado.

O canteiro nº 3 (atrás do palco) permaneceu bloqueado e vazio.

(V4: 1h 52min) - Banheiros químicos limitaram a visão do público

14:32 - Adiante, uma linha confusa de banheiros químicos quase não deixava espaço para o público — mantido pelas grades a uns 10 metros do meio-fio.

Quem estava mais atrás, não tinha visão do desfile, nem encontrava passagem. — Os mais empolgados subiam nos banheiros para poder ver.

Posse presidencial (II) - gramado do Congresso

2003

(V1: 22 min) - a multidão invade o gramado do Congresso

Em 2003, assim que o Rolls Royce chegou à Alameda dos Estados, em poucos minutos a multidão ocupou o gramado do Congresso Nacional.

(V1: 24 min) - pessoas se jogam na água

Pessoas jogam “presentes” para Lula. — Uma moça se joga no carro em movimento e consegue abraçá-lo. — Pessoas se jogam no espelho d’água para chegar mais perto. — A segurança mal sabia o que fazer.

(V1: 26 min) - a multidão ocupa o gramado frontal do Congresso

Pelo que se vê no vídeo, boa parte dessas pessoas acompanharam o desfile de Lula no Rolls Royce desde a Catedral — alguns, subindo nas poucas árvores ao longo do trajeto, para descer de novo em seguida — e muitas, correndo para chegar primeiro ao lugar seguinte do trajeto.

(V1: 2h 5m) - público no gramado do Congresso à espera da saída de Lula para o Planalto

Após 1 hora 30 minutos de permanência de Lula no Congresso Nacional, o público no gramado frontal estava “estabilizado” — com 3 ou 4 espaços vazios, inclusive um retângulo reservado aos canhões para a salva de tiros. — A concentração é maior junto ao espelho d’água, e ao longo das vias por onde o Rolls Royce deveria seguir para o Palácio do Planalto (do lado direito da imagem).

Os canteiros nº 3 a 5 da Esplanada estavam quase vazios, vendo-se ao fundo o palco montado junto à via L2 (próximo à Catedral) para o show dos artistas.

(V1: 2h 30m) - Seguranças empurram o Rolls Royce na saída da garagem do Senado

Quando Lula sai do Congresso, acontecem 2 coisas que confundem e dispersam a multidão: — O Rolls Royce toma um atalho imprevisto, sem dar tempo de a maior parte da multidão se deslocar para a Praça dos Três Poderes; — e mais tarde, Lula abandona o Parlatório do Palácio do Planalto por mais de 30 minutos, em um gesto de gentileza a Fernando Henrique Cardoso, enquanto o povo e os chefes de Estado esperavam sua volta para ouvir o discurso no Parlatório.

(V1: 2h 29) - Multidão ainda espera Lula na Alameda e na via N1

Pela contagem de tempo do Vídeo nº 1 (V1):

2h 27m - Enquanto passa a Esquadrilha da Fumaça (após a salva de 21 tiros da Artilharia), o Rolls Royce com Lula desce para a garagem do Senado e segue pela via N2 até a garagem do Planalto — em vez de subir para a Alameda dos Estados e descer pela via N1, onde era esperado pelo público.

2h 28m - Alexandre Garcia se dá conta da mudança de trajeto e começa a especular sobre o atalho que “provavelmente” seria utilizado.

2h 29m - A maior parte do público presente no gramado do Congresso, na Alameda e na via N1 ainda não se moveu.

(V1: 2h 31m) - Multidão do lado sul do Congresso desce para os Três Poderes

2h 31m - Grande número de pessoas que estavam na via S1 — portanto, fora do percurso previsto — se adiantam e descem para a Praça dos Três Poderes.

2h 33m - Lula chega ao Palácio do Planalto.

2h 38m - Lula já recebeu a faixa presidencial de Fernando Henrique. — Muitas pessoas ainda estavam a caminho da Praça dos Três Poderes (pela S1). — Não há imagens de quando a maior parte das pessoas no gramado do Congresso se deram conta da mudança e começaram a se mover (ou não) pela via N1.

2h 42m - Lula desce do Parlatório para acompanhar Fernando Henrique Cardoso até uma saída discreta (não pela rampa) — e, durante os 30 minutos finais do vídeo, não volta para falar ao povo que estava na Praça.

2019

Apenas canhões no gramado do Congresso, na posse de Bolsonaro

Na posse de Bolsonaro, o gramado do Congresso permaneceu quase inteiramente bloqueado — ocupado pelos canhões para a salva de tiros. — O público permaneceu confinado em 2 retângulos pequenos (ver abaixo); e além da Alameda dos Estados (canteiro nº 3 e via N1).

(V2: 1h 50m) - Câmera do alto dá uma visão ampla do público diante do Congresso

Finalmente, uma câmera do alto do Anexo I do Senado oferece uma visão ampla do público, contido para lá da Alameda dos Estados — ocupando menos da metade do canteiro nº 3 e um curto trecho da via N1.

(V2: 2h 5m) - Um close do cercadinho norte, visto do alto

Outra imagem do alto, em zoom, permite calcular a área do cercadinho em 80 m × 30 m = 2.400 m² — mas se a densidade fosse de 1 pessoa / m², não seria possível ver tanta grama entre as pessoas.

Não há público em nenhum dos lados da via N1 — da Alameda dos Estados até a esquina da Praça dos Três Poderes. — Nenhum deslocamento de público entre o Congresso Nacional e a Praça dos Três Poderes: eram públicos estanques.

2023

(V4: 1h 56 min) - Repetiu-se o esquema dos cercadinhos

14:36 - Em 2023, com o canteiro nº 3 bloqueado e a repetição dos 2 cercadinhos nas pontas da Alameda dos Estados, não houve correria, nem invasão do gramado frontal do Congresso.

Por sinal, o público não se empolgou muito em ficar confinado — sabia-se lá durante quantas horas — e os cercadinhos tiveram baixa demanda.

Mais tarde, o cercadinho sul (acima) se esvaziou. — Seu público se juntou ao do cercadinho norte (com a bandeira LGBTQIA+), para ver a saída rumo ao Planalto.

(V4: 2h 3min) - Gramado do Congresso vazio: o público assistiu para lá do palco

14:43 - O pequena abertura angular da imagem de Lula e Alckmin chegando ao Congresso não permite ver esses 2 cercadinhos nas extremidades do gramado — e não havia canhões, pois foi dispensada a tradicional salva de tiros na saída.

O público permaneceu para lá do palco — nos canteiros nº 4 e 5.

(V4: 3h 35min) - Público na Esplanada depois da posse no Congresso

16:15 - Terminada a cerimônia de posse no Congresso Nacional, Lula e Alckmin reúnem-se em privado com os presidentes da Câmara e do Senado — e o Festival do Futuro é retomado, com mais uma série de apresentações.

A imagem aérea (acima) registra o público presente diante do palco — no canteiro nº 4 (à direita, embaixo) — e na praça de alimentação do Festival Gastronômico, no canteiro nº 5 (no alto, à esquerda).

(V4: 3h 43min) - Aglomeração na via N1, no alto, à direita

16:23 - No detalhe (acima), uma parte do público já se aglomera na barreira da via N1 (no alto, à direita) para aguardar a passagem do Rolls-Royce com Lula, rumo ao Palácio do Planalto.

O alinhamento do palco com o “bloco U” (agora: Turismo, e Minas e Energia) permite verificar que deixava ao público 288 metros do canteiro nº 4 — e menos de 200 metros de largura, devido às barreiras afastadas do meio-fio.

(V5) - Público entre a Praça de Alimentação (à esq.) e o Festival do Futuro

16:22 - Nesse detalhe (acima), o restante do público entre o Festival do Futuro (canteiro nº 4, à direita) e a Praça de Alimentação (canteiro nº 5, à esquerda).

Posse presidencial (III) - Praça dos Três Poderes

2003

Praça dos Três Poderes na posse de Lula em 1º Janeiro 2003

Na foto de Lula e José Alencar subindo a rampa do Palácio do Planalto (acima), pode-se ver um público enorme, até mais ao fundo — mas a pequena abertura angular (zoom?) oculta a largura, muito maior, da Praça dos Três Poderes.

Esse ângulo baixo, pouco acima da horizontal, contribui para “adensar” a multidão ao fundo, criando uma impressão grandiosa — o que é ótimo para empolgar a galera — mas ruim para uma avaliação objetiva.

(V1: 2h 17m) - Multidão na Praça (esq.) e nos gramados do Senado e da Câmara (dir.)

Há muitas indicações de que a Praça não estava tão lotada quanto parece. — Parte do público se espalhava pelos gramados da Câmara e do Senado (à direita) — mas a maior parte dos que estavam no gramado frontal do Congresso não teve tempo para descer, nos escassos 5 ou 6 minutos do atalho tomado pelo Rolls Royce.

(V1: 2h 28m) - Densidade da multidão na Praça, quando Lula saía do Congresso

Acima - Densidade da multidão na Praça dos Três Poderes, no momento em que o Rolls-Royce entrava pela garagem do Senado para chegar mais rápido ao Planalto.

(V1: 2h 38m) - Densidade do público na Praça, na passagem da faixa presidencial

Acima: - Por poucos segundos, a TV Globo exibiu imagens tomadas do alto, quando Lula se preparava para receber a faixa presidencial de Fernando Henrique. — Há uma concentração razoável de pessoas “nas primeiras filas” da Praça dos Três Poderes, mas não tanto, logo atrás. — Imagem analógica, com borrões.

(V1: 2h 55min) - Helicóptero ao vivo, ou VT feito mais cedo?

Bem mais tarde, Alexandre Garcia anuncia: “Agora, imagens de helicóptero” — mas não diz se eram ao vivo, ou VT feito mais cedo. — O sol já ia baixo, e não sei se as pessoas ainda precisavam entrar no espelho d’água, para aliviar o calor.

De qualquer modo, 12 minutos depois de Lula e FHC saírem do Parlatório, seria natural o público se dispersar — mas permanece a dúvida, se esta imagem não seria um video-tape (VT) de 1 ou 2 horas antes, como era comum na TV da época.

Além disso, não se vêem pessoas descendo para os Três Poderes pela via S1.

(V1: 2:59) - Pessoas ainda descendo a via S1, da Esplanada para os Três Poderes

Apenas 4 minutos depois, de volta às câmeras ao vivo — zoom, possivelmente desde o Anexo IV da Câmara dos Deputados, a 600 metros do Planalto — podem-se ver muitas pessoas ainda descendo da Esplanada para a Praça dos Três Poderes, pela via S1 — e uma distribuição do público, na praça, bem diferente do que sugerem as imagens de helicóptero.

Infelizmente, com tão poucas imagens ainda na web, após 20 anos — e de tão baixa resolução — tudo é mais difícil.

E, como diz o novo ditado: — “Ainda não se usavam drones, como atualmente”.

(V3: 0 min) - Público na Praça dos Três Poderes ao final do discurso de Lula

É preciso relacionar o “tempo” de cada vídeo com o horário real. — O vídeo do SBT faz isso — mas começa bem depois do final do vídeo da Globo.

Aos 10 minutos do vídeo (V3: 10 min), quando Lula partia do Palácio no Rolls Royce para o desfile em zig-zag pelo canteiro central da Esplanada, Hermano Henning informa que eram 18:30 (Horário de verão).

Acima: - Público nas primeiras filas da Praça dos Três Poderes, no momento em que Lula termina seu discurso no Parlatório, cerca de 18:20.

2019

Praça dos Três Poderes na posse de Bolsonaro, 1º Janeiro 2019

A foto do Poder360 (acima), com maior abertura angular (e boa luz solar), oferece 2 informações ausentes na foto “equivalente” da 1ª posse de Lula: — (a) Visão bem mais larga das primeiras fileiras de pessoas perto do meio-fio; e (b) A visão de grande espaço vazio ao fundo, em especial à esquerda.

(V2: 1h 5m ~ 2h 40m) Público sem alteração na Praça dos Três Poderes

O público presente à Praça dos Três Poderes para a posse de Bolsonaro permaneceu praticamente inalterado por mais de 1 hora 30 minutos. — Mais uma vez, nenhuma imagem mostra pessoas se deslocando.

Do lado esquerdo, o público ocupa cerca de 80 metros, da via N1 até pouco atrás da estátua dos Dois Candangos, e pouco antes do início da antiga Casa de Chá.

(V2: 1h 5m) - Público nos Três Poderes para a posse de Bolsonaro

Do lado direito, o público ocupa cerca de 130 metros, até o Museu Histórico.

A média é de 105 metros desde a via N1 — e a frente ficou limitada a 125 metros — o que dá uma área ocupada de cerca de 13.000 m².

Nenhum público nos gramados do Senado e da Câmara ou nas vias adjacentes — e nenhuma movimentação de público da Esplanada para os Três Poderes.

Público na Praça dos Três Poderes cerca das 17:00 (Horário de Verão)

Uma foto de Adriano Machado (Reuters), publicada às 17:52 (Horário de Verão), pelo G1 Globo, resume todas essas observações. — A sombra bem nítida do Anexo I do Senado permite calcular que foi feita perto das 17:00 (Horário de Verão).

Nenhum público na nesga de Praça do lado de lá da via proveniente do STF.

2023

Público nos Três Poderes, após Lula receber a faixa das mãos de populares

Mais uma vez, o ângulo baixo, quase horizontal, reforça a grandiosidade do público na Praça dos Três Poderes, no momento em que Lula já recebeu a faixa das mãos de pessoas representativas do povo brasileiro.

Público nos Três Poderes durante o discurso no Parlatório

Dessa vez, temos imagens suficientes para avaliar o público presente à Praça dos Três Poderes, do começo ao fim da tarde — e salta aos olhos que a segurança não deixou entrar 40 mil pessoas.

Na avaliação do site Poder360, haveria cerca de 24 mil a 32 mil pessoas.

Posse presidencial (IV) - gramado da Esplanada

2003

(V3: 12 min) - Multidão sobe a N1 com Lula para o desfile na Esplanada

É mais difícil avaliar o público em torno de Lula, a partir do momento em que o Rolls Royce sobe a via N1, do Planalto para a Esplanada — onde desfila em zig-zag pelo canteiro central, até a Catedral de Brasília. — As áreas ocupadas são irregulares; e quanto mais se afasta do Anexo I do Senado, mais baixo é o ângulo da câmera.

Acima: - O público da Praça dos Três Poderes e dos gramados próximos acompanha o Rolls Royce, ocupando as laterais da via N1 — e a própria via, atrás do carro.

(V3: 16 min) - Início do desfile em zig-zag no gramado da Esplanada

O público se desloca o tempo todo, à medida em que o Rolls Royce faz seu zig-zag pelo canteiro central da Esplanada — e não existe “geometria” que facilite uma avaliação do número de pessoas — correndo em todas as direções.

(V3: 20 min) - Aglomerações na Esplanada e no espaço desde a Rodoviária

Além das aglomerações ao longo do zig-zag — e das pessoas que se deslocam o tempo todo, para chegar ao trecho seguinte...

Havia uma aglomeração de barracas no canteiro nº 7, para lá da via L2 — onde a revisão da Folha / Defesa Civil DF detectou um público maior do que no centro do gramado frontal do Congresso, durante a posse perante o Parlamento.

(V3: 28 min) - Público ainda voltando dos Três Poderes para a Esplanada

A câmera do alto do Anexo I do Senado mostra que, quando Lula chegou de novo à Catedral, muitas pessoas ainda voltavam da Praça dos Três Poderes para a Esplanada, pelas vias N1 e S1.

2023

(V4: 10h 30min) - Lula no palco do Festival do Futuro

23:10 - É difícil avaliar o público presente no Festival do Futuro no final da noite, quando Lula, Janja, Alckmin e Lu subiram ao palco — após o jantar oferecido no Itamaraty aos chefes de Estado e delegações estrangeiras — pois os drones já tinham ido dormir.

(V4: 8h 43min) - Última panorâmica por drone, às 21:23

21:23 - A última panorâmica por drone no público do Festival do Futuro foi quase 2 horas antes — e mostrava aglomeração até o 3º par de torres (pelo menos), com menor densidade nas laterais — mas naquele momento ficou no escuro o restante do espaço até a Praça de Alimentação, mais ao fundo.

(V4: 8h 54min) - Praça de Alimentação por volta das 21:34

21:34 - A última panorâmica por drone ainda mostrava movimento bastante razoável na Praça de Alimentação — considerando que não foi possível lotar um espaço tão amplo em nenhum momento ao longo da tarde — e pode-se perceber alguma presença de público na área sem iluminação que a separa do Festival, propriamente dito.

(V4: 11h 32min) - Público no Festival do Futuro às

0:12 - Numa das últimas tomadas do público com iluminação geral, não é possível perceber qualquer nova redução do número de pessoas — mas o ângulo baixo e a falta de foco na base do 3º par de torres não permitem afirmar nada.

É óbvio que era um público menor do que à tarde — se mais não fosse, porque muitas caravanas deviam retornar a suas cidades às 22:00, saindo do Ginásio de Esportes, a 3 km da Esplanada — e por isso, seus participantes não poderiam permanecer no Festival após o anoitecer.

Mas qualquer afirmação de que diminuiu muito — ou de que diminuiu pouco — não encontra embasamento nesse conjunto de imagens.

A guerra dos números (I)

Público estimado pela PM-DF em 2003, na Época e no Estadão

Apenas 3 semanas depois da 1ª posse de Lula, a Folha de S. Paulo questionou os números divulgados por toda a “grande mídia” — inclusive ela mesma — quanto ao público presente ao evento.

Começou por resumir — com falhas — o que se havia publicado:

A Folha afirmou haver cerca de 150 mil pessoas, com base em informações da Polícia Militar. A PM foi alterando suas estimativas ao longo do dia. Logo após o almoço, falava em 70 mil. No final da tarde, chegou aos 150 mil.

"O Globo" registrou na sua primeira página a presença de 200 mil pessoas, segundo "os organizadores". Nas páginas internas, atribuía aos organizadores a estimativa de 150 mil a 200 mil, e, segundo a PM, 70 mil — sem especificar o horário em que esse número da polícia havia sido coletado. (...)

(Acima - Na verdade, tanto a revista Época quanto o Estadão atribuíram à PM-DF a estimativa de “cerca de 200 mil” pessoas).

Para “arbitrar”, a Folha de S. Paulo resolveu submeter à Defesa Civil do DF “fotos aéreas da Esplanada” nos “horários de maior concentração de público” — às 15:30, “quando Lula saiu da Câmara” (V1: 2:20 ~ 2:27) — e às 18:15, quando Lula falava do Parlatório (minutos antes de V3: 0:00).

PDF da página do jornal impresso

Os técnicos da Defesa Civil calcularam a “área ocupada” na “Esplanada”, às 15:30, em nada menos que 296.521 m² — desde o canteiro nº 8, quase na Rodoviária, até o gramado do Congresso (incluídos) — pegando grupos dispersos por toda parte, os maiores dos quais, um de 7.208 pessoas no centro do gramado do Congresso (junto ao espelho d’água) e outro de 12.000 pessoas no canteiro nº 7, perto da Catedral.

Já para a Praça dos Três Poderes, calcularam 13.468 pessoas em uma área total de 32.835 m², às 18:15 — mas avaliaram que, às 15:30, havia apenas 60% disso — daí, a conta de 8.080 pessoas (60% de 13.468), para compatibilizar os horários.

Infelizmente, a Folha não lembrou de fazer o mesmo, no tocante a essa questão na posse de Bolsonaro — o que invalida comparações.

Vale notar que essa conta tenta ser um “instantâneo” — um momento único, fixo, congelado — enquanto, em São Paulo, o DataFolha considera “público total” = a soma de todos os que “passaram” por uma área “ao longo da tarde”, ou “ao longo do dia”, chegando com facilidade a cifras de 1 milhão de pessoas, em áreas bem menores, e muito mais difíceis de verificar.

Enfim, em São Paulo o DataFolha rejeita terminantemente o uso de fotos aéreas — única base dessa “revisão” da posse de Lula em Brasília, 2003.

A guerra dos números (II)

Blogs noticiam a maior posse do universo, em 2019

Às 19:05 (Horário de Verão) do dia 1º Jan. 2019, a Gazeta do Povo já tinha o número de “115 mil pessoas” na posse de Bolsonaro — e que seria maior do que a soma dos públicos nas posses de Lula e Dima. — No mesmo dia, o blog “Agência Caneta” elevou a posse de Bolsonaro à categoria de “a maior da história”.

Foto de Nelson Almeida, usada pela Gazeta do Povo e pelo UOL

Só quase 1 horas mais tarde, às 19:55 (*), o portal UOL publicou o mesmo número de “115 mil pessoas” — mas frisando que isto não superava o público presente à posse de Lula em 2003.

(*) O horário da publicação da Gazeta do Povo é “relativo” (UTC - fuso horário atual) — ao passo que o horário da publicação do UOL permanece “fixo”. — Ver “Ferramentas”, adiante.

Tanto a Gazeta do Povo quanto o UOL utilizaram a mesma foto, de Nelson Almeida (AFP), em zoom, fechado no único ponto de maior aglomeração, ao norte da Alameda dos Estados (ver V2: 2h 5m).

Durante 3 dias, a torcida pôde compartilhar à vontade a versão que melhor lhe conviesse — até que, no dia 4 Jan. 2019, a “plataforma jornalística Aos Fatos” tentou botar alguma ordem na bagunça, observando o óbvio: — Não é possível comparar números de 3 fontes diferentes, que utilizaram 3 “metodologias” totalmente diferentes:

Os números de 70 mil, 150 mil e 200 mil pessoas na posse de Lula em 2003 foram dados, em diferentes horários, pela PM-DF — sempre utilizada como fonte, pela mídia, para eventos em Brasília.

O número de 71 mil pessoas na posse de Lula em 2003 foi dado, semanas depois, por uma análise de fotos aéreas, encomendada pela Folha de S. Paulo à Defesa Civil do DF — que não esteve lá para isso, no dia; e que nunca mais foi chamada a tratar disso, antes ou depois.

O número de “115 mil pessoas” na posse de Bolsonaro em 2019 foi dado pelo GSI — o gabinete de segurança da Presidência, já sob comando de aliados políticos de Bolsonaro. — Nesse dia, pela primeira vez em décadas, a PM-DF não divulgou avaliação do número de pessoas presentes.

Não deixa de ser gentileza, atribuir uma “metodologia” ao GSI — que deu explicações vagas e confusas. — Nem “Aos Fatos”, nem a Folha, criticaram ou “revisaram” esse número (que eu saiba).

Por tudo que se vê nos vídeos de 2003 e 2019, a 1ª posse de Lula reuniu um público pelo menos 4 vezes maior, na Esplanada — independente de quaisquer “números” indicados por fontes diferentes, com “metodologias” diferentes.

Quanto à multidão nos Três Poderes, é mais difícil comparar, pois em 2003 o público se espalhava por toda a praça e adjacências (além de receber reforço), enquanto em 2019 o público ali ficou parado, concentrado, “bem comportado”. — Além disso, grandes portais mudaram seus links ao longo desses 20 anos, eliminando ou dificultando encontrar fotos de 2003, com as horas exatas — e os vídeos que encontrei são de baixa resolução.

O tempo não para

Tropas do Exército na via N2, em Maio 2017: início da militarização

Não houve barreiras nem revista (que eu me lembre, ou encontre na web), na 1ª posse de Lula, em 2003. — Cheguei muito cedo, e não guardo lembrança de qualquer obstáculo — nem de precisar estacionar longe, ou andar muito.

Também não houve obstáculos à chamada “Marcha dos 100 mil” (ruralistas), em 1999 — nem às sucessivas manifestações contra a Reforma da Previdência de 2003, no 1º governo Lula.

Isto só começou em 2016, para evitar atritos entre manifestantes pró × contra o Impeachment — e se exacerbou a partir da reação militarista do governo Temer às manifestações contra ele — em especial a partir da G.L.O. de 2017.

Tornou-se prática permanente durante o governo Bolsonaro — e se impôs à 3ª posse de Lula em 2023 — até por insegurança quanto ao comportamento da própria “segurança” herdada do período Bolsonaro.

Referências

71 mil foram à posse de Lula, revela estudo - (PDF) - Folha de S. Paulo - 22 Jan. 2003
Quantas pessoas cabem na Avenida Paulista? - Época - 22 Mar. 2015 / 26 Out. 2016
Entenda como são feitos os cálculos de público da PM e do Datafolha - Veja - 16 Mar. 2015 / 5 Dez. 2016
Posse de Bolsonaro atrai 115 mil pessoas e não supera a de Lula em 2003 - UOL - 1º Jan. 2019
Posse de Bolsonaro atrai mais público do que de Lula e Dilma juntas - Gazeta do Povo - 1º Jan. 2019
Multidão lota Praça dos Três Poderes e crianças brincam com cão da PM durante posse de Bolsonaro - G1 Globo - 1º Jan. 2019
Comparação entre público de posses presidenciais mistura metodologias diferentes - Aos Fatos - 4 Jan. 2019
Ato de Bolsonaro em Brasília teve mais de 100 mil pessoas - Poder360 - 7 Set 2022
Lula toma posse diante de centenas de milhares, recebe a faixa de representantes do povo e defende a democracia - G1 / Globo - 1º Jan 2023
Lula toma posse e sobe a rampa: dezenas de milhares acompanham cerimônia em Brasília - BBC News Brasil - 1º Jan 2023
Público da posse de Lula supera 7 de Setembro de Bolsonaro - Poder360 - 2 Jan 2023

Vídeos

Posse Presidencial - Lula (01/01/2003) - Rede Globo

[Final] Posse do Presidente - Lula | SBT (01/01/2003)

Posse Bolsonaro: acompanhe a íntegra da cerimônia - TV Senado
Posse de Lula na Presidência do Brasil - Lula (Youtube) - 1º Jan 2023

A posse do presidente Luiz Inácio Lula da Silva - TV PT - 1º Jan 2023
Cobertura especial da Posse Presidencial ao vivo - TV Senado - 1º Jan 2023
Presidente Luiz Inácio Lula da Silva toma posse em Brasília - TV Record - 1º Jan 2023

Ferramentas

Camadas guardadas no GE Desktop

GE Desktop - Costumo usar o GoogleEarth “Desktop” (aplicativo para PC), mas de alguns anos para cá, ele vem perdendo funcionalidades. — Agora, a “altitude” (acima do nível do mar), indicada como “elev” (elevação) no canto inferior à direita, é sempre “zero” — e no Google Maps, também.

Em todo caso, é muito prático poder salvar inúmeros lugares, medidas e contornos em uma pasta “Esplanada” — para ter sempre à mão algumas distâncias, como a dos postes, por exemplo (21,4 metros ou seus múltiplos) — e a opção de ocultar ou exibir cada camada, com um clique, daí por diante.

Imagem dos Três Poderes em Janeiro 2019 no GE Desktop

Também é muito prático poder escolher entre sucessivas “imagens históricas” de cada local. — Imagens de “21 Janeiro 2019” tendem a ser mais fieis à realidade do terreno no início daquele mês.

Distância e elevação (altitude) do asfalto, no GE Web

GE Web - Para verificar as elevações do terreno e do teto dos prédios, tive de recorrer ao GoogleEarth “Web” (navegador) — que também é mais prático para medir distâncias e áreas — mas ainda não descobri como salvá-las, para não ter de fazer tudo de novo, caso precise outra vez.

Aliás, essas medidas aparecem em um retângulo preto, inamovível, que atrapalha a produção das imagens. — Ao fechá-lo, as medidas desaparecem.

Quanto à data das imagens, esqueça. — A única certeza é que todas foram feitas após 1º Jan. 1970: o início da “era do Unix”. — Parece que os desenvolvedores do GE Web não querem lidar com isso, no momento.

Elevação do Anexo I do Senado, no GE Web

Com isso, foi fácil medir a extensão da sombra do Anexo I do Senado, na foto de Adriano Machado (Reuters) — e a altura relativa do topo do prédio até o asfalto (1.152 - 1.059 = cerca de 93 metros) — para determinar o ângulo de elevação do sol naquele momento (cerca de 36º).

Aproveitei o recurso “medir área” para desenhar um triângulo — legendado mais tarde, no Gimp — para ilustrar o cálculo do ângulo de elevação do sol.

Hora aproximada da foto (Horário de Verão), pelo KStars

KStars - Recuando até 1º Jan. 2019 no KStars, pode-se verificar que a elevação do sol a 36º ocorreu perto das 17:00 (Horário de Verão) — cerca de 52 minutos antes da publicação feita pelo portal G1 Globo, às 17:52 (Horário de Verão).

São números aproximados, pois o GoogleEarth não favorece maior exatidão.

Portanto, mesmo sem os dados Exif da imagem, pode-se saber que a foto não é de 2 ou 3 horas antes — e de qualquer modo, o público na Praça dos Três Poderes não se alterou desde várias horas antes.

Diferenças de “hora de publicação” entre 2019 e 2022

Horário de Verão - Em Janeiro de 2003 e 2019 vigorava o Horário de Verão (UTC-0200) — que foi extinto apenas em Abril 2019.

Isto vale para os horários da programação oficial, para as horas faladas durante os vídeos — mas não, necessariamente, para as páginas na internet.

O software gerenciador de conteúdo (CMS) do G1 Globo (acima) guardou a hora de publicação pelo “tempo universal” (UTC) — ISSUED: "2019-01-01T19:52:44.187Z" — mas exibe no fuso horário atual (e local) do internauta.

Em 2019, G1 Globo (acima) exibia “17:52” — e hoje exibe “16:52”. — A indicação original ainda pode ser vista nas capturas do Wayback Machine feitas na época.

A mesma coisa acontece com o CMS Wordpress utilizado pela Gazeta do Povo, que exibia “19:05” na época; e hoje exibe “18:05” — mas a publicação do UOL exibe até hoje a mesma hora “19:55” que exibia na época.

Luz difusa - Infelizmente, nessa época do ano, em Brasília, é muito comum o céu encoberto (alternando sol, mormaço, chuvas ocasionais) — dando lugar a uma luminosidade difusa, sem sombras definidas. — Por isso, boa parte das fotos não permite determinar a hora em que foram feitas.

Cópias de referência - Imprimi em PDF as notícias da época, para guardar — e salvei no Wayback Machine (Internet Archive), para prevenir eventuais sumiços ou alterações (de Novembro para Dezembro 2022, por exemplo, a matéria da revista Época, passou a ficar sob paywall do portal G1 Globo). Estes são os links indicados nas Referências. — As fotos foram baixadas em separado.

Pelos mesmos motivos, baixei os vídeos pelo yt-dlp (Youtube Download Plus).

Tratamento de imagens - Tratei a maior parte das imagens no Gimp, apenas para redução automática de infravermelho / ultra-violeta (Colours > Auto > White balance) — mas em alguns casos isso “esverdeava” a captura de vídeo, e me limitei a aumentar manualmente o brilho e o contraste (Colours > Brightness-Contrast).

Sincronização dos vídeos da TV Senado (V5) e da TV Lula (V4)

Sincronização - Às 14:29 de 1º Jan 2023, o vídeo da TV Senado registra o início do desfile do Rolls-Royce, em frente à Catedral de Brasília — o que, no vídeo da “TV Lula”, corresponde a (V4: 1h 48min). — Como o vídeo da TV Senado começou às 10:00, calculei o início do vídeo da TV Lula às 12:40.

__________________________
Publicado em 5 Nov. 2022; e desenvolvido até 28 Dez. 2022.
Reformulado em 15 Mar. 2023, para incluir a 3ª posse de Lula.

— … ≠ • ≠ … —

Quantas pessoas cabem na Esplanada dos Ministérios?

Conky altera o cálculo da Memória RAM usada

Conky - monitor do sistema

Transição para hardware UEFI-GPT

Grub enlouquecido com 12 distros em multiboot

De volta ao Gnome-screenshot

Redcore Linux - instalação e configuração

noreply@blogger.com (Mboaba) — Tue, 14 Jun 2022 12:48:01 +0000

Redcore Linux instalado e atualizado

Redcore se propõe "levar o poder do Gentoo para as massas" — por isso, foi a distro que escolhi para substituir o saudoso Sabayon como "distro de entrada" para esse ramo do Linux.

A instalação do Redcore Linux Hardened 2102 (=2021 nº 2, lançado em Outubro 2021) transcorreu sem qualquer problema — e a atualização inicial se completou na segunda tentativa, com as demoras que, afinal, eram previstas e avisadas.

As demais atualizações se completaram sem problemas — exceto alguns casos específicos, relatados mais à frente.

Por enquanto, uso o comando sisyphus para atualizar o sistema, e para procurar e instalar novos pacotes — nunca o Discover. — Evito usar o emerge (Portage), enquanto aprendo (para não me confundir); e comecei a explorar as flags USE.

A instalação de pacotes adicionais também não foi difícil, mesmo sem conhecimento anterior do Redcore ou do Gentoo. — Ainda não consegui instalar algumas coisas bem comuns, como o GoogleEarth; enquanto o Dolphin continua sem algumas características encontradas em todas as outras distros que já instalei, como exibir os dados Exif das fotos — mas tenho trabalhado com o Redcore Linux sem grandes dificuldades, nos últimos 40 dias.

Isto NÃO é um tutorial — mas, apenas, um registro da minha experiência (com possíveis erros, que ainda não percebi). — Estruturar um relato, como este, me obriga a revisar cada detalhe, solucionar problemas, deixar a distro bem afinada, aprender coisas novas — e fico feliz se for útil aos colegas que se aventuram no mundo Linux sem serem "especialistas".

Meu hardware atual é bastante razoável para compilar meia-dúzia de pacotes em algumas atualizações (que faço aos domingos) — mas acabei desativando o Intel Turbo Boost (eu não jogo), por motivos que explico adiante:

      Mobo: TUF B360M-PLUS GAMING/BR, BIOS 2401 03/22/2019 - ASUSTeK
      iGPU: Intel Corporation UHD Graphics 630 (Desktop)
Processors: 6 × Intel® Core™ i5-9400 CPU @ 2.90GHz (min / max: 800 ~ 4100 MHz)
    Memory: 15.5 GiB of RAM

Índice

Download
Particionamento
Instalação
Atualização inicial
Sisyphus
Configurações
CPU e Temperatura
Dolphin
Flags USE
Redcore 2201
“There is NOT at least 6400 MiB disk space at...”
Por que Redcore Linux?

Download

Download da ISO do Redcore Linux 2102 pelo navegador

12 Junho 2022 - Clicar nos links da página de downloads do Redcore Linux não produz nenhum resultado, no meu navegador. — No ano passado, cliquei em cada item com o botão direito do Mouse para "copiar o link", e em seguida colei no Terminal, para fazer o download com o wget.

Este ano, cliquei com o botão direito do Mouse e escolhi "salvar o link como". — O navegador iniciou os downloads, mas parou no final. — No rodapé do navegador, um aviso de que "não pode ser baixado com segurança".

Cliquei na seta ao lado dos botões "descartar", fui à página de downloads do navegador — cliquei em "manter" (tive de confirmar) — e finalmente os arquivos foram salvos no HDD.

No ano passado, a velocidade de download passou um pouco de 20 MiB/s (segundo o Conky) e a média ficou em 16,9 MB/s (segundo o wget); — e este ano, chegou a 21,7 MiB/s (segundo o Conky) — o que está bem perto do limite de 26,1 MiB/s da minha conexão de "200 megas".

Isso me animou bastante, pois prenunciava boas velocidades de download também nas atualizações. — A imagem ISO veio da Universidade de Princeton, nos EUA — país ao qual a internet do Brasil está umbilicalmente conectada.

Depois de instalado, verifiquei que o Sisyphus já veio configurado para usar o espelho de Princeton — o que é bom, pois a conexão do Brasil com a Europa é indireta (passando pelos EUA) — e com a Rússia nunca foi boa (hoje, talvez, pior):

# sisyphus mirror list
1   http://mirrors.redcorelinux.org/redcorelinux/amd64/packages/
2   http://mirrors.redcorelinux.org/redcorelinux/amd64/packages-next/
3 * http://mirror.math.princeton.edu/pub/redcorelinux/amd64/packages/
4   http://mirror.math.princeton.edu/pub/redcorelinux/amd64/packages-next/
5   http://mirror.alpix.eu/redcorelinux/amd64/packages/
6   http://mirror.alpix.eu/redcorelinux/amd64/packages-next/
7   http://mirror.yandex.ru/mirrors/redcorelinux/amd64/packages/
8   http://mirror.yandex.ru/mirrors/redcorelinux/amd64/packages-next/

Por enquanto, evito os repositórios "packages-next" (testing).

Verificação sha256sum com ajuda do KWrite

Fiz a verificação da imagem ISO do Redcore Linux pelos comandos sha256sum e md5sum e colei os resultados no campo de busca do KWrite, para não errar nem perder tempo.

"Queima" do DVD pelo K3b, na menor velocidade disponível

"Queimei" o DVD pelo K3b, na menor velocidade permitida pelo hardware — um hábito que adotei há alguns anos, para reduzir perdas de mídia.

Particionamento

Criando partições e "movendo" para elas o Mocaccino

Não gosto de usar instaladores para particionar discos, pois nem sempre fazem o que penso ter entendido de suas interfaces. — Prefiro fazer o particionamento antes, usando o GParted ou o KDE Partition Manager, dos quais já sei exatamente o quê esperar.

O primeiro passo foi criar 2 novas partições e "colar" nelas (copy & paste) as partições Linux11 e Home11 — onde estava o Mocaccino OS. — Em seguida, alterei os Rótulos das cópias para Linux11b e Home11b, para evitar confusão, pois uso esses Rótulos na montagem automática (udisks2), no Conky, e até no /etc/fstab do Debian.

Formatando e tornando a rotular Linux11 e Home11

Por fim, formatei as partições Linux11 e Home11 originais — para mudar seus identificadores UUID — e tornei a aplicar esses rótulos.

Instalação

Início da sessão Live do Redcore Linux

Infelizmente, não encontrei nenhum aplicativo de captura de tela na sessão Live — por isso, tive de me conformar com fotos (bem ruins) pelo celular.

O instalador (Calamares) é muito prático. — Para começar, troquei o Idioma inglês "americano" pelo inglês do Reino Unido; selecionei o Fuso horário BRT; e Teclado Brasil (padrão = ABNT2).

Na etapa "Partições", selecionei "Particionamento manual" — para ter completa liberdade de escolher as partições que iria usar, e que já estavam prontas. — Talvez a opção "Substituir uma partição" servisse para fazer isso, mas preferi não arriscar.

Selecionei e "editei" as partições Linux11 para "raiz" (/), Home11 para a pasta pessoal (/home) — sempre verificando que não estivessem marcadas para formatar.

Antes de prosseguir, o instalador reclamou que faltava escolher a partição EFI. — Selecionei, editei, e me certifiquei de que não estava marcada para formatar.

Tentei selecionar também a partição Swap, mas não vi como fazer isso. — É fácil habilitar Swap mais tarde.

Na etapa "Usuários", dei ao computador o nome "Redcore" (era para ser Linux11, mas foi bom para identificar melhor no celular) — selecionei Login Automático — e criei uma senha separada para o Administrador (Root).

Resumo das escolhas, antes de realizar a instalação efetiva

Antes de efetivar a instalação no computador, o instalador apresenta um resumo das escolhas feitas pelo usuário — e esta é a última oportunidade para corrigir alguma coisa.

Obs.: - O Live Redcore Linux inverteu as posições de sda e sdb — e foram os Rótulos das partições (Linux11, Home11, EFI), visíveis na etapa "Partições", que me ajudaram a evitar algum desastre.

Depois de instalado, às vezes ainda inverte sda e sdb — e outras vezes inverte sdb e sdc.

A instalação efetiva foi menos demorada do que eu esperava — cerca de 20 minutos (de DVD para SSD), contados pela hora das fotos — e para variar, os percentuais da barra de progresso do Calamares guardam pouca relação com a realidade.

Atualização inicial

Início da primeira atualização

A primeira atualização do Redcore Linux previa atualizar 984 pacotes binários — mas abortou após baixar 633, em 1 hora 19 minutos:

# date; sisyphus upgrade; date
Sun 12 Jun 16:54:24 -03 2022

These are the binary packages that would be merged, in order:
(...)
Total: 984 binary package(s)

Would you like to proceed? [y/N] y

(...)
>>> Downloading binary (632 of 984) gui-libs/libwpe-1.12.0.tbz2
100% [..............................................................] 83034 / 83034

>>> Downloading binary (633 of 984) media-libs/libplacebo-4.192.1.tbz2
Traceback (most recent call last):
  File "/usr/lib/python3.9/urllib/request.py", line 1786, in open
    return getattr(self, name)(url)
(...)
  File "/usr/lib/python3.9/socket.py", line 832, in create_connection
    sock.connect(sa)
OSError: [Errno socket error] [Errno 110] Connection timed out
Sun 12 Jun 18:13:12 -03 2022

Tornei a executar o comando de atualização — e ele anunciou que iria baixar 984 pacotes binários — sem nenhum desconto pelos 633 baixados minutos antes.

Dessa vez, a atualização se concluiu sem qualquer falha, após 3 horas 51 minutos, e no final deixou 420 linhas de mensagens para ler.

Velocidades de download durante o upgrade do Redcore Linux

A demora não se deve à velocidade de download, que atinge bons níveis — mas às interrupções ao final de cada pacote (picos isolados) — com grandes intervalos entre um pacote e outro.

Isso lembra um pouco o comportamento das atualizações no Sabayon — que costumava baixar 3 pacotes de cada vez, interrompendo o download por algum tempo, depois baixava mais 3 pacotes, e assim por diante.

Poucos momentos de intensa atividade de processamento

Houve poucos momentos de intensa atividade de processamento. — Como ainda não entendo do assunto, só posso imaginar que houve alguma compilação, aqui e ali. — E mesmo depois de terminado o download geral, alguma coisa ainda precisou ser baixada pelo emerge (acho), durante o processamento.

Como resultado dessa atualização, que cobre 8 meses, desde o lançamento da ISO (Outubro 2021), o KInfocentre indica as diferenças de Kernel e Plasma:

2022-06-12 16:48:41                                    |   2022-06-13 00:17:38
                                                       |
      Operating System: Redcore Linux Hardened         |         Operating System: Redcore Linux Hardened
    KDE Plasma Version: 5.22.5                         |       KDE Plasma Version: 5.24.5
KDE Frameworks Version: 5.86.0                         |   KDE Frameworks Version: 5.93.0
            Qt Version: 5.15.2                         |               Qt Version: 5.15.3
        Kernel Version: 5.14.10-redcore (64-bit)       |           Kernel Version: 5.14.21-redcore (64-bit)

Sisyphus

Enfim, captura de tela no Redcore Linux

É claro que aproveitei esse tempo — do final da instalação, às 16:29, até o final da atualização, às 22:12 — para fazer pequenas configurações, principalmente no KDE Plasma.

Mas só depois da atualização poderia instalar algumas ferramentas mais urgentes — e aí já me deparei com a eventual necessidade da opção --ebuild do Sisyphus:

# history | grep install
  ...
   11                      date; sisyphus install conky; date
   16                      date; sisyphus install gnome-screenshot --ebuild; date
   19                      date; sisyphus install kdeconnect; date
   24  2022-06-12_22-42-36 date; sisyphus install inxi ; date
   26  2022-06-12_22-44-38 date; sisyphus install screenfetch; date
   28  2022-06-12_22-46-03 date; sisyphus install neofetch; date
   50  2022-06-12_23-50-37 date; sisyphus install kate; date
   56  2022-06-13_00-59-44 date; sisyphus install krename --ebuild; date
   58  2022-06-13_01-15-59 date; sisyphus install google-chrome; date
   94  2022-06-14_08-54-17 date; sisyphus install dmidecode --ebuild; date
  116  2022-06-14_23-16-39 date; sisyphus install kruler --ebuild; date
  124  2022-06-15_21-25-54 date; sisyphus install corefonts; date
  132  2022-06-16_11-21-23 date; sisyphus install kdesdk-thumbnailers --ebuild; date
  137  2022-06-16_11-31-21 date; sisyphus install baloo-widgets --ebuild; date
  142  2022-06-16_11-42-42 date; sisyphus install kdegraphics-mobipocket --ebuild; date
  152  2022-06-16_12-18-02 date; sisyphus install krusader --ebuild; date
  190  2022-06-16_15-51-22 date; sisyphus install konqueror --ebuild; date
  237  2022-06-17_10-48-12 date; sisyphus install app-text/html2text --ebuild; date
  267  2022-06-18_10-28-21 date; sisyphus install filelight --ebuild; date
  269  2022-06-18_10-29-58 date; sisyphus install kdiff3 --ebuild; date
  289  2022-06-19_17-20-43 date; sisyphus install youtube-dl --ebuild; date
  298  2022-06-20_11-36-05 date; sisyphus install imagemagick --ebuild; date
  305  2022-06-20_16-23-59 date; sisyphus install foliate --ebuild; date
  307  2022-06-20_16-34-50 date; sisyphus install kstars --ebuild; date
  ...
  300  2022-06-20_22-19-45 date; sisyphus install foliate --ebuild; date
  311  2022-06-22_10-01-06 date; sisyphus install app-misc/screen --ebuild; date
  315  2022-06-22_10-24-57 date; sisyphus install www-client/links --ebuild; date
  336  2022-06-30_13-23-53 date; sisyphus install scrcpy --ebuild; date
  382  2022-07-17_15-33-24 date; sisyphus install media-libs/libexif; date
  389  2022-07-18_12-18-18 date; sisyphus install kde-apps/marble; date
  393  2022-07-19_14-10-00 date; sisyphus install app-misc/mc --ebuild
  477  2022-07-21_01-45-01 date; sisyphus install net-analyzer/speedtest-cli --ebuild; date

Por padrão, o Sisyphus só lida com pacotes binários — mas quando não encontra, ele poderá avisá-lo, caso existam ebuilds — arquivos do repositório Gentoo com a informação que o Portage necessita para manter o software (instalar, procurar).

Então, você repete o comando, acrescentando essa opção — mas, para não perder tempo, é melhor usá-la sempre. — A opção --ebuild (ou apenas -e) pode ser usada o tempo todo, pois ela dá preferência aos pacotes binários, se nenhuma compilação for necessária.

Com um comando sisyphus search dolphin, por exemplo, eu encontrei apenas 3 pacotes — mas com a opção --ebuild encontrei 8 pacotes.

Vale notar que o sisyphus install só aceita o nome simples do pacote, se ele for “único“. — Caso contrário, dirá que não encontrou. — Neste caso, é preciso especificar “Categoria/Pacote”.

Midnight Commander no Sisyphus GUI

Mesmo na busca, deixar de indicar a Categoria pode dificultar as coisas. — Levei 3 dias para encontrar o Midnight Commander (mc) — brigando com o reduzido sisyphus --help (pois não existe man sisyphus).

Por fim, me deparei na web com o “nome completo”— app-misc/mc — e só mais tarde descobri que, pelo Sisyphus GUI, (acima) eu não teria gastado nem 1 minuto:

# history | grep 'mc\|midnight\|commander'
   61  2022-06-13_10-27-38   sisyphus install mc
   62  2022-06-13_10-28-38   sisyphus install midnight-commander
  149  2022-06-16_12-15-14   sisyphus search commander --ebuild
  157  2022-06-16_14-25-24   sisyphus search commander -d -e
  158  2022-06-16_14-26-56   sisyphus search commander -d 'file manager' -e
  159  2022-06-16_14-28-01   sisyphus search commander -d 'Midnight Commander'' -e
  160  2022-06-16_14-28-21   sisyphus search commander -d 'Midnight Commander' -e
  191  2022-06-16_19-03-36   sisyphus search mc --ebuild
  192  2022-06-16_19-06-04   sisyphus search mc -d 'commander' --ebuild
  193  2022-06-16_19-06-30   sisyphus search mc -d 'midnight commander' --ebuild
  194  2022-06-16_19-06-52   sisyphus search "" -d 'midnight commander' --ebuild
  196  2022-06-16_19-09-08   sisyphus search app-misc* -d 'midnight commander' --ebuild
  200  2022-06-16_19-11-08   sisyphus search root/app-misc/mc/mc-4.8.28-r1.ebuild --ebuild
  201  2022-06-16_19-11-27   sisyphus search mc-4.8.28-r1.ebuild --ebuild
  410  2022-07-19_14-08-23   sisyphus search app-misc/mc --ebuild
  411  2022-07-19_14-10-00   sisyphus install app-misc/mc --ebuild

Olhando agora o histórico dos comandos, é fácil ver quantos erros de “lógica” eu cometi — mas na hora, a situação parecia desanimadora.

Enfim, até uma simples busca implica em nova consulta aos repositórios. — O Sisyphus não dá 1 passo sem verificar tudo de novo. — Se você fizer 10 buscas, uma após outra, terá 10 demoras iniciais.

Para desocupar espaço em disco, após 4 dias (16 Jun) usei o comando # sisyphus autoremove — que remove pacotes órfãos. — Isso reduziu em 2,4 GiB o uso da partição-raiz (de 16,9 para 14,5 GiB).

Para contar os pacotes instalados, usei o comando # qlist -I | wc -l — que apontou o mesmo número indicado pelo Neofetch (1.454, naquele momento). — Para guardar uma lista de todos os arquivos instalados, usei o comando # qlist -I > qlist--installed.txt (pena que não era mais a instalação original, para documentar).

Outros 2 comandos permitiram registrar mais detalhes dos pacotes instalados:

# sisyphus search "" -f installed >> installed.txt

# sisyphus search "" -f alien >> installed-alien.txt

Este último comando encontrou 8 pacotes "alien": — podofo, baloo, baloo-widgets, krename, krusader, gnome-screenshot, além do vimcommander (que instalei à toa) e uma biblioteca libhandy.

Falta ler mais algumas coisas sobre liberar espaço em disco — em especial eclean.

Configurações

Nome e versão do init do Redcore Linux, no Conky (imagem posterior)

Para a linha do Conky que exibe o software init e sua versão:

${sysname} ${kernel} ${alignr}\
${execi 600 echo $(strings /sbin/init | awk 'match($0, /(upstart|systemd|sysvinit|busybox|runit|openrc|S6|66-boot)/) { print substr($0, RSTART, RLENGTH);exit; }')} \
${execi 600 rc-service -V | cut -c 21-26}

... utilizei um vetusto comando strings (ainda do tempo do upstart) — e em seguida, o recém-aprendido comando rc-service (Gentoo, Alpine Linux) — cujo resultado colei no Kate / KWrite, para “contar“ a posição a ser usada no comando cut:

# echo $(strings /sbin/init | awk 'match($0, /(upstart|systemd|sysvinit|busybox|runit|openrc|S6|66-boot)/) { print substr($0, RSTART, RLENGTH);exit; }')
openrc

$ rc-service -V
rc-service (OpenRC) 0.42.1 (Redcore Linux Hardened)
         1         2         3         4         5
123456789012345678901234567890123456789012345678901234567890

$ rc-service -V | cut -c 12-26
(OpenRC) 0.42.1

$ rc-service -V | cut -c 21-26
0.42.1

Dividi a linha em 3 pedaços (\) nas configurações do Conky, para facilitar minha vida:

1) Os primeiros 2 trechos (sysname, kernel, strings) são válidos em todas as 12 distros que mantenho instaladas — o que facilita manter um "modelo" de arquivo de configuração facilmente aplicável a qualquer distro, mesmo em sessão Live.

2) O comando strings me dá a certeza de qual init está de fato em uso — pois em algumas distros pode haver mais de 1 instalado. — Assim, evito indicar o init errado, caso escolhesse (por engano) apenas um comando específico... de outro:

[PATH]/Warehouse/Byteria/Conky/backup/2022-07-18

$ grep -R -A 2 sysname

openSUSE   ${sysname} ${kernel} ${alignr}\
           ${execi 600 echo $(strings /sbin/init | awk 'match($0, /(upstart|systemd|sysvinit|busybox|runit|openrc|S6|66-boot)/) { print substr($0, RSTART, RLENGTH);exit; }')} \
           ${execi 600 systemctl --version | grep systemd | cut -c 9-11}

Arch       ${sysname} ${kernel} ${alignr}\
           ${execi 600 echo $(strings /sbin/init | awk 'match($0, /(upstart|systemd|sysvinit|busybox|runit|openrc|S6|66-boot)/) { print substr($0, RSTART, RLENGTH);exit; }')} \
           ${execi 600 systemctl --version | grep systemd | cut -c 9-11}

Debian     ${sysname} ${kernel} ${alignr}\
           ${execi 600 echo $(strings /sbin/init | awk 'match($0, /(upstart|systemd|sysvinit|busybox|runit|openrc|S6|66-boot)/) { print substr($0, RSTART, RLENGTH);exit; }')} \
           ${execi 600 systemctl --version | grep systemd | cut -c 9-11}

Fedora     ${sysname} ${kernel} ${alignr}\
           ${execi 600 echo $(strings /sbin/init | awk 'match($0, /(upstart|systemd|sysvinit|busybox|runit|openrc|S6|66-boot)/) { print substr($0, RSTART, RLENGTH);exit; }')} \
           ${execi 600 systemctl --version | grep systemd | cut -c 9-11}

KDE Neon   ${sysname} ${kernel} ${alignr}\
           ${execi 600 echo $(strings /sbin/init | awk 'match($0, /(upstart|systemd|sysvinit|busybox|runit|openrc|S6|66-boot)/) { print substr($0, RSTART, RLENGTH);exit; }')} \
           ${execi 600 systemctl --version | grep systemd | cut -c 9-11}

PCLinuxOS  Kernel ${sysname} ${kernel} ${alignr}\
           ${execi 600 echo $(strings /sbin/init | awk 'match($0, /(upstart|systemd|sysvinit|busybox|runit|openrc|S6|66-boot)/) { print substr($0, RSTART, RLENGTH);exit; }')} \
           ${execi 600 strings /sbin/init | grep INIT_VERSION | cut -c 23-30}

Mageia     ${sysname} ${kernel} ${alignr}\
           ${execi 600 echo $(strings /sbin/init | awk 'match($0, /(upstart|systemd|sysvinit|busybox|runit|openrc|S6|66-boot)/) { print substr($0, RSTART, RLENGTH);exit; }')} \
           ${execi 600 systemctl --version | grep systemd | cut -c 9-11}

Slackware  ${sysname} ${kernel} ${alignr}\
           ${execi 600 echo $(strings /sbin/init | awk 'match($0, /(upstart|systemd|sysvinit|busybox|runit|openrc|S6|66-boot)/) { print substr($0, RSTART, RLENGTH);exit; }')} \
           ${execi 600 strings /sbin/init | grep INIT_VERSION | cut -c 23-30}

Void       ${sysname} ${kernel} ${alignr}\
           ${execi 600 echo $(strings /sbin/init | awk 'match($0, /(upstart|systemd|sysvinit|busybox|runit|openrc|S6|66-boot)/) { print substr($0, RSTART, RLENGTH);exit; }')}

Manjaro    ${sysname} ${kernel} ${alignr}\
           ${execi 600 echo $(strings /sbin/init | awk 'match($0, /(upstart|systemd|sysvinit|busybox|runit|openrc|S6|66-boot)/) { print substr($0, RSTART, RLENGTH);exit; }')} \
           ${execi 600 systemctl --version | grep systemd | cut -c 9-11}

Redcore    ${sysname} ${kernel} ${alignr}\
           ${execi 600 echo $(strings /sbin/init | awk 'match($0, /(upstart|systemd|sysvinit|busybox|runit|openrc|S6|66-boot)/) { print substr($0, RSTART, RLENGTH);exit; }')} \
           ${execi 600 rc-service -V | cut -c 21-26}

MX Linux   ${sysname} ${kernel}  ${alignr}\
           ${execi 600 echo $(strings /sbin/init | awk 'match($0, /(upstart|systemd|sysvinit|busybox|runit|openrc|S6|66-boot)/) { print substr($0, RSTART, RLENGTH);exit; }')} \
           ${execi 600 strings /sbin/init | grep INIT_VERSION | cut -c 23-30}

3) Apenas o terceiro trecho é específico de cada distro — comandos escolhidos à mão, caso por caso (com base na resposta ao comando strings), para obter a versão do respectivo init — o que ainda não descobri como fazer no Void Linux.

Memória, Processos e Pacotes do Redcore Linux, no Conky (imagem posterior)

No bloco do Conky que exibe várias medidas desencontradas do uso de Memória RAM (Conky2, à direita), desabilitei a linha do htop — pois ainda não encontrei o pacote aha (Ansi HTML Adapter), necessário para converter a saída em formato web. — Até agora, só encontrei o html2text, que completaria a conversão para texto puro (plain text).

Mem:               ${alignr 100}up  ${uptime}

Total - Available  ${alignr 100}${exec bash MemInfo.sh; cat MemInfo.txt}
Conky (Mem)        ${alignr 100}${mem}
free               ${alignr 100}${exec free -m | grep Mem | cut -c 25-35} MiB
top                ${alignr 100}${exec top -E m -b -n 1  | grep buff | cut -c 41-50} MiB
neofetch           ${alignr 100}${exec neofetch  --stdout | grep "Memory" | grep -o -P '.{0,0}Memory.{0,9}' | cut -b 8-12} MiB
# htop               ${alignr 100}${exec echo q | htop | aha --line-fix | html2text | grep -o -P '.{0,6}/15' | cut -b 1-6}iB
inxi               ${alignr 100}${exec inxi --memory-short | grep -o -P '.{0,0}used.{0,14}' | cut -b 6-14}
screenfetch        ${alignr 100}${exec screenfetch -n -N | grep -o -P '.{0,0}RAM.{0,9}' | cut -b 5-12}

${execi 600 neofetch  --de_version on --stdout | grep "Packages:"}

${execi 600 neofetch  --de_version on --stdout | grep "DE:"}
${execi 600 kf5-config --version | grep 'Qt\|KDE'}
${execi 600 konsole -v} ${alignr 60}${execi 600 kate -v}
${execi 600 dolphin -v} ${alignr 60}${execi 600 gwenview -v}

${execi 600 neofetch  --de_version on --stdout | grep "CPU\|GPU"}
$hr

Datação do histórico dos comandos no arquivo .bashrc (imagem posterior)

Por volta de 22:40, lembrei de datar os comandos no .bash_history — tanto do usuário quanto do Administrador. — A data e a hora dos comandos só passa a ser registrada após fechar e reiniciar o Konsole (como fiz); ou de imediato, recarregando suas configurações pelo comando source:

$ echo 'export HISTTIMEFORMAT="%F_%H-%M-%S "' >> ~/.bashrc
$ source ~/.bashrc

# echo 'export HISTTIMEFORMAT="%F_%H-%M-%S "' >> ~/.bashrc
# source ~/.bashrc

$ history
    2  2022-06-12_22-40-26 su
    3  2022-06-12_22-40-26 su
    4  2022-06-12_22-40-26 sensors
    6  2022-06-12_22-40-26 su
    7  2022-06-12_22-40-26 echo 'export HISTTIMEFORMAT="%F_%H-%M-%S "' >> ~/.bashrc
    8  2022-06-12_22-40-32 history

# history
    1  2022-06-12_22-40-55 sisyphus mirror list
    2  2022-06-12_22-40-55 date; sisyphus spmsync; date
    3  2022-06-12_22-40-55 date; sisyphus update; date
    4  2022-06-12_22-40-55 date; sisyphus upgrade; date
    5  2022-06-12_22-40-55 date; sisyphus upgrade; date
    7  2022-06-12_22-40-55 date; sisyphus upgrade; date
   11  2022-06-12_22-40-55 date; sisyphus install conky; date
   16  2022-06-12_22-40-55 date; sisyphus install gnome-screenshot --ebuild; date
   18  2022-06-12_22-40-55 date; sisyphus search kdeconnect; date
   19  2022-06-12_22-40-55 date; sisyphus install kdeconnect; date
   21  2022-06-12_22-40-55 echo 'export HISTTIMEFORMAT="%F_%H-%M-%S "' >> ~/.bashrc
   22  2022-06-12_22-41-00 history

Os comandos executados antes desse momento permanecem não-datados — e aparecem com a data e hora do momento em que se executa o comando history. — Por isso, eu não saberia quando instalei o Conky, o gnome-screenshot e o KDE Connect (sem recorrer aos logs do sistema), se não incluísse date no início e no final dos comandos sisyphus.

Para procurar nos logs, o genlop aceita parâmetros que permitem selecionar, por exemplo, após a atualização inicial e o dia seguinte:

# genlop --list --date Sun 12 Jun 22:20:00 2022 --date Mon Jun 13 22:00:00 2022

     Sun Jun 12 22:25:19 2022 >>> net-wireless/wireless-tools-30_pre9-r1
     Sun Jun 12 22:25:23 2022 >>> dev-lang/lua-5.3.6-r3
     Sun Jun 12 22:25:27 2022 >>> app-admin/hddtemp-0.3_beta15-r29
     Sun Jun 12 22:25:32 2022 >>> net-libs/libircclient-1.10
     Sun Jun 12 22:25:37 2022 >>> app-admin/conky-1.12.2
     Sun Jun 12 22:30:20 2022 >>> gui-libs/libhandy-1.6.2
     Sun Jun 12 22:30:30 2022 >>> media-gfx/gnome-screenshot-41.0
     Sun Jun 12 22:34:16 2022 >>> x11-libs/libfakekey-0.3-r1
     Sun Jun 12 22:34:20 2022 >>> dev-libs/kpeoplevcard-0.1-r1
     Sun Jun 12 22:34:24 2022 >>> media-libs/pulseaudio-qt-1.3-r1
     Sun Jun 12 22:34:28 2022 >>> net-fs/sshfs-3.7.1
     Sun Jun 12 22:34:33 2022 >>> kde-misc/kdeconnect-22.04.0
     Sun Jun 12 22:43:11 2022 >>> sys-apps/inxi-3.3.13.1
     Sun Jun 12 22:45:11 2022 >>> app-misc/screenfetch-3.9.1-r1
     Sun Jun 12 22:46:28 2022 >>> app-misc/neofetch-7.1.0-r1
     Sun Jun 12 23:51:06 2022 >>> kde-apps/kate-22.04.0
     Mon Jun 13 01:00:47 2022 >>> app-text/podofo-0.9.7
     Mon Jun 13 01:01:09 2022 >>> kde-misc/krename-5.0.1-r1
     Mon Jun 13 01:17:17 2022 >>> www-client/google-chrome-101.0.4951.64

22:54 - Várias coisas dependiam da montagem automática de partições adicionais — que eu estava evitando, para não criar pontos de montagem pertencentes ao Administrador. — Para isso, eu precisava criar um arquivo /etc/polkit-1/rules.d/99-udisks2.rules e colar nele uma autorização para a montagem dessas partições pelo udisks2 sem privilégios:

# history
   37  2022-06-12_22-54-52 nano /etc/polkit-1/rules.d/99-udisks2.rules

Pasted content:

# cat /etc/polkit-1/rules.d/99-udisks2.rules
// 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; } });

Criando atalhos para o gnome-screenshot no Redcore Linux KDE

Ainda precisei instalar inxi, Screenfetch, Neofetch — e configurar os atalhos para o gnome-screenshot:

PrtScn                                       --- capturar e salvar
gnome-screenshot -p -f PATH/$(date +%F_%H-%M-%S)_Rc.jpg
Shift+PrtScn                                 --- com espera de 7 segundos
gnome-screenshot -p -d 7 -f PATH/$(date +%F_%H-%M-%S)_Rc.jpg
CTRL+Shift-PrtScn                            --- capturar janela ativa
gnome-screenshot -w -p -f PATH/$(date +%F_%H-%M-%S)_Rc.jpg

Instalando fontes a partir de arquivos locais

Executei o sensors-detect, para configurar o sensors, necessário para o Conky exibir as Temperaturas de modo correto. — Instalei algumas fontes a partir de velhos arquivos locais e executei o comando # fc-cache -fv para atualizar o cache de fontes.

Habilitando Compositor para obter Transparência no Redcore KDE

Por algum motivo, o Compositor de Tela ainda precisava ser habilitado para as sessões do Plasma KDE, para obter Transparência no Conky, no Painel, no Menu (tema Maia Transparent, originário do Manjaro) e na decoração das janelas (Transparent Oxygen).

Isso também aconteceu no Debian testing, há alguns meses.

Copiando scripts de outra partição /home

Copiei da /home de outra distro (Home10) o script MemInfo.sh, que calcula o uso de Memória RAM conforme proposto por Linus Torvalds em 2014 — para vigiar os cálculos do Conky e das demais ferramentas:

MEM_TOTAL=$(awk '/MemTotal/ { printf $2 }' /proc/meminfo); \
MEM_AVAIL=$(awk '/MemAvailable/ { printf $2 }' /proc/meminfo); \
MEM_USED_KILO="$(($MEM_TOTAL-$MEM_AVAIL))"; \
echo "$(($MEM_USED_KILO/1024))" MiB > MemInfo.txt

(*) Me parece incorreto dividir (MemTotal - MemAvailable) / 1024, pois o “kB” (com k minúsculo) no /proc/meminfo é muito claro em se referir ao sistema SI (portanto, o divisor deveria ser 1024² / 1000 = 1048,576) — mas essa parece ser a prática adotada pelos desenvolvedores das várias ferramentas — e a diferença de +2,4% é irrelevante, dadas as oscilações normais de uso de RAM a cada segundo.

Montagem pelo UDisks2 e cópia de Autostarts do Conky

Enfim, montei manualmente as partições adicionais pelo Dolphin (udisks2) e ocultei as que uso pouco. — Com a perspectiva de montagem automática (a seguir), aproveitei para copiar de outra distro os arquivos de início automático do Conky.

Uma segunda instância do Conky exige outro arquivo de configuração

13 Jun 2022 - Uma segunda instância do Conky, precisa de outro arquivo de configuração:

conky -c /home/flavio/.config/conky/conky2.conf

(comando do início automático do Conky 2).

Montagem automática de todas as partições

Pelo KDE System Settings >> Removable storagem >> Removable devices, podem-se marcar uma ou várias partições adicionais para montagem automática no início da sessão Plasma pelo UDisks2 (sem incluí-las no fstab) — ou marcar todas com apenas 1 clique, no alto.

Dependendo da distro, basta fazer isso 1 vez — ou um punhado de vezes. — Depois, a montagem automática se normaliza e só em raros casos volta a falhar.

No Redcore Linux, a montagem automática só passou a funcionar por completo depois de vários Restart — e para isso, torno a montar manualmente as que faltam, pelo Dolphin, até adestrar o UDisks2. — Mas voltou a falhar algumas vezes, ao longo da semana.

Inversão de sdb e sdc no Redcore Linux

Primeiro, atribuí essas falhas ao fato de que, às vezes, o Redcore inverte as posições de sda e sdb — e outras vezes inverte sdb e sdc — embora os dispositivos estejam sempre plugados nos slots Sata nº 1, Sata nº 2, Sata nº 3.

Manter a lista dos "Dispositivos desconectados"

Esse talvez fosse um dos motivos pelo quais o KDE System Settings desenvolve uma longa lista de "dispositivos desconectados" — com as mesmas partições montadas no momernto (logo acima). — Com o tempo, todas as possíveis alternativas acabaram sendo "cadastradas" e lembradas, e a montagem automática passou a funcionar em todas as inicializações do sistema.

Nesse afã de normalizar a montagem automática das partições adicionais, resolvi deletar logo as partições do Mocaccino OS — sem lembrar das anotações e capturas de tela que ainda estavam em sua /home.

Entre um Restart e outro, comecei a configurar o Kate e o KWrite — e prossegui nas semanas seguintes.

Dando ao Usuário a posse dos pontos de montagem do Redcore

Outro dos possíveis motivos, é que vários pontos de montagem pertenciam ao Administrador (Root) — um problema que eu já tinha enfrentado em outras distros, após um upgrade do KDE — e que atrapalha a montagem automática pelo UDisks2.

Na minha ingenuidade, eu também achava que uma das "vantagens" de usar pontos de montagem em /media/$USER/ ou em /run/media/$USER/ fosse sua "limpeza" completa, ao encerrar a sessão do Usuário — quando essa pasta é esvaziada (ou deveria ser).

Para "ver" a situação "de fora", carreguei o openSUSE (1 semana mais tarde) — e descobri que persiste uma cópia de /run/media/$USER/ na pasta /var. — Aliás, descobri que isso também ocorre em outras distros (eu nunca tinha notado).

Lá estavam os tais pontos de montagem pertencentes ao Administrador. — Portanto, de nada adiantariam meus esforços para corrigir isso por comandos como, p.ex., # chown 1000:1000 /run/media/#USER/[mountpoint] dentro do próprio Redcore — pois no boot seguinte a situação anterior seria restabelecida a partir da cópia na pasta /var.

Então, executei o comando chown 1000:1000 nos pontos de montagem, nesse "backup" guardado na pasta /var do Redcore — a partir do openSUSE.

Reiniciei o computador — o Redcore Linux montou, automaticamente, todas as partições adicionais (dessa vez, pelo menos!) — e até agora não explodiu nada.

Recebendo fotos do celular pelo KDE Connect

Ainda na primeira hora do dia 13, liberei o KDE Connect para o celular, para poder baixar logo as fotos da instalação e da atualização inicial:

# history
   52  2022-06-13_00-50-07 iptables -I INPUT -p tcp --dport 1714:1764 -j ACCEPT
   53  2022-06-13_00-50-20 iptables -I INPUT -p udp --dport 1714:1764 -j ACCEPT

Abrir pasta com o KRename

Configurei uma associação de arquivos para o KRename ser a segunda opção de "abrir pastas", no menu de contexto do Dolphin — o que facilita renomear rapidamente todas as fotos recém-baixadas. — Renomeio com o mesmo padrão "data+hora" que uso nas capturas de tela e no histórico de comandos, o que facilita reuni-los em sequência cronológica (numa pasta ou em um arquivo TXT).

Colocando o ícone do Redcore Linux no Menu

Substituí o ícone do Menu, quase invisível, pelo do Redcore, em vermelho vivo. — Habilitei no Menu a seção de aplicativos e arquivos usados recentemente. — Desabilitei a "expansão" de sua Busca, que incluía Favoritos (Bookmarks), Arquivos e Emails.

Substituição do Task Manager pelo Icons-only Task Manager

Substituí o Gerenciador de Tarefas tradicional por outro só de ícones.

Tempos depois, desabilitei o “Mute” nos ícones do Chrome e do WhatsChrome.

Reconfigurei o "Zoom In", de 1,2x para 3,0x de cada vez — o que facilita capturar detalhes do Conky sem perder tempo.

Habilitando o Blur

Habilitei o Blur, que por algum motivo estava inativo. — Com isso, o Menu do Maia Transparent ficou legível.

Agendamento do script para 10 minutos após o boot

Corrigi o bash script RAM.sh (copiado de outra distro) — que salva informações do uso de Memória — e agendei para ser executado 10 minutos após o boot. O tempo de ir buscar um café e ver se o mundo ainda está lá fora.

Linhas longas demais nas mensagens do Sisyphus

Toda vez que eu abria a sessão do Kate com as anotações sobre o Redcore, eu recebia uma mensagem de "linha longa demais". — Sim, o Sisyphus colocou as pastas, os nomes e as versões de todos aqueles 984 pacotes da atualização inicial em uma única linha de 28.664 caracteres, com 2 espaços em branco separando uns dos outros.

Selecionei aquela linha descomunal — basta Shift-End (2 vezes) — cortei e colei num arquivo provisório, para ver o que se poderia fazer com aquilo.

Nesses casos, o Google me manda logo para o Stackoverflow — a partir dali, pesquisei o comando sed para mais dicas — e acabei resolvendo o problema:

   $ sed -i.backup 's/  /\n/g' try1.txt

Em resumo, eu queria substituir cada 2 espaços por uma quebra de linha — e finalmente consegui uma bela lista de 984 linhas, que o Kate / KWrite aceita com um sorriso.

Desabilitando a detecção de outras distros pelo Grub do Redcore

No /etc/default/grub, retirei os parâmetros quiet splash (para ver o que acontece no boot) — adicionei uma linha GRUB_DISABLE_OS_PROBER="true" (pois não preciso que ele perca tempo detectando outras distros) — e executei a atualização do Grub, para que essas mudanças sejam incorporadas ao Grub do Redcore Linux.

Naturalmente, mais tarde reinicializei o computador e carreguei o openSUSE, cujo Grub é meu Menu de inicialização. — Ao atualizar o Grub do openSUSE, ele “lê” o Grub das outras distros, e incorpora essas mudanças que fiz no Redcore Linux.

Personalização do Gimp

14 Jun 2022 - Ao iniciar a sistematização deste relato, personalizei o Gimp. — Desmembrei a "janela única", descartei a caixa da direita, simplifiquei o Toolbox (à esquerda), adicionei a ele a aba Camadas, apliquei um Tema escuro, criei 2 atalhos (X para Crop, S para salvar como) etc. — e salvei logo as Opções de Ferramentas, para não perder todas essas configurações se faltar luz antes de fechá-lo.

Habilitando a partição Swap

15 Junho 2022 - Finalmente lembrei de habilitar a partição Swap. — Como não sei quais parâmetros o Redcore Linux prefere, analisei os arquivos /etc/fstab das outras distros e adotei os parâmetros mais "populares" entre elas — em especial, PCLinuxOS, Slackare e MX Linux (o Void usa none swap sw 0 0):

[PATH] /Warehouse/Byteria/Hardware--Partitions/etc-fstab/2022-06-13_Redcore/

$ cat * | grep swap

01        UUID=a6bc03e6-ae71-4504-a8f5-c7bc79021e96  swap   swap   defaults   0  0
02        UUID=a6bc03e6-ae71-4504-a8f5-c7bc79021e96  none   swap   defaults   0  0
03        UUID=a6bc03e6-ae71-4504-a8f5-c7bc79021e96  none   swap   sw         0  0
04        UUID=a6bc03e6-ae71-4504-a8f5-c7bc79021e96  swap   swap   defaults   0  0
05        UUID=a6bc03e6-ae71-4504-a8f5-c7bc79021e96  none   swap   sw         0  0
06        UUID=a6bc03e6-ae71-4504-a8f5-c7bc79021e96  swap   swap   defaults   0  0
07        UUID=a6bc03e6-ae71-4504-a8f5-c7bc79021e96  swap   swap   defaults   0  0
08        /dev/sdb16                                 swap   swap   defaults   0  0
09        UUID=a6bc03e6-ae71-4504-a8f5-c7bc79021e96  none   swap   sw         0  0
10        UUID=a6bc03e6-ae71-4504-a8f5-c7bc79021e96  none   swap   defaults   0  0
12        UUID=a6bc03e6-ae71-4504-a8f5-c7bc79021e96  swap   swap   defaults   0  0

17 Jun 2022 - O Night Colour não detectou minha localização. — Tive de inserir manualmente Latitude e Longitude — que felizmente tenho sempre à mão.

CPU e Temperatura

CPU a 100ºC ao instalar KStars

20 Jun 2022 - A instalação do Foliate levou cerca de 7 minutos, com alto uso de CPU, elevadas temperaturas, chegando em alguns momentos a 100ºC — e a ventoinha do cooler uivando como uma alma penada.

A instalação do KStars demorou cerca de 7 minutos — com a ventoinha do cooler uivando a todo vapor — e longos períodos a 100ºC.

Uma pesquisa rápida apresentou vários tópicos no fórum do Gentoo — de pessoas perguntando se temperaturas de 100ºC são normais, ao compilar pacotes — e vários colegas respondendo que o normal é ficar na faixa de 50ºC ~ 60ºC.

Trocar a pasta térmica e limpar a ventoinha do cooler não é um bicho-de-7-cabeças — mas os registros do início de 2020 (quando as peças do computador tinham acabado de sair das embalagens) mostram que eu obteria uma redução de, no máximo, 11ºC, e provavelmente nem metade disso. — Portanto, a solução deveria estar em outro lugar.

Void, PCLinuxOS e KDE Neon inativos até 10 minutos após o boot

O exame de mais alguns registros mostrou que várias das minhas distros ficam pouco acima de 800 ou 900 MHz, quando em repouso — e vão a 3.900 ~ 4.000 MHz numa fração de segundo, quando necessário.

Isso está de acordo com a velocidade-base de 800 MHz e “Intel Turbo Boost” até 4.100 MHz, nas especificações. — Ou, segundo o inxi: “Speed: 800 MHz | min / max: 800 / 4100 MHz (...)”.

Slackware e Redcore Linux inativos até 10 minutos após o boot

Uma exceção era o Slackware, que costuma oscilar sempre nas proximidades de 4.000 MHz — e pelo que vejo agora, também o Redcore Linux. — Mas quando a compilação de pacotes começa a aquecer demais os núcleos, o Redcore reduz a frequência para 3.600 ~ 3.700 MHz, mantendo o limite de 100ºC.

Compilação sem “Intel Turbo Boost” e sem aquecimento, no Redcore

Alguma coisa no fórum do Gentoo me levou a desativar o “Intel Turbo Boost” no UEFI Bios Setup, para testar o comportamento.

Depois disso, o Redcore já iniciou na frequência de 2.900 MHz e apresentou temperaturas levemente menores do que em todas as sessões da última semana (detalhe do alto, acima).

Removi o Foliate, expurguei os pacotes órfãos, e tornei a instalar o Foliate:

# history
  314  2022-06-20_22-15-20 date; sisyphus uninstall foliate; date
  316  2022-06-20_22-17-38 date; sisyphus autoremove; date
  318  2022-06-20_22-19-45 date; sisyphus install foliate --ebuild; date

Dessa vez, a instalação do Foliate levou cerca de 8 minutos e meio — as temperaturas ficaram na faixa de 60ºC ~ 70ºC (detalhe ao centro, acima), e a frequência se manteve em 2.900 MHz, sem redução alguma. — Agora, sim, a limpeza da ventoinha do cooler e a troca da pasta térmica poderão reduzir essas temperaturas para a faixa de 50ºC ~ 60ºC.

A partir dessas observações, minhas leituras sobre o Redcore Linux (e o Gentoo) ganham mais um sentido. — Se entendi direito, pode-se reduzir isso por meio de algumas flags aqui e ali.

Até hoje, eu nunca tinha pensado em desabilitar o “Intel Turbo Boost”. — Mas não jogo, nem costumo fazer processamentos intensivos — exceto, agora, as compilações do Redcore.

Por princípio, o Turbo é eficiente em reduzir a frequência para manter a Temperatura máxima em 100ºC — e com isso posso ganhar alguns minutos nas grandes atualizações — mas o uivo desesperado da ventoinha do cooler é estressante demais para o meu gosto.

Essa foi a melhor decisão, como percebi ao mexer nas flags USE — e um dia, a recompilação de 35 pacotes demorou 3 horas 10 minutos, com a CPU no máximo a maior parte do tempo. — Mal se ouviam pequenas acelerações da ventoinha do cooler — o que é muito mais confortável do que ganhar 20 minutos, com um uivo desesperado, por 3 horas.

Apenas aproveitei para navegar na web e botar vários assuntos em dia, como se nada estivesse acontecendo.

Dolphin

Painel Informações (F11) do Dolphin, no KDE Neon

16 Junho 2022 - Dolphin sem a opção de exibir o painel “Informações” (F11), do lado direito, foi uma "novidade" difícil de lidar, nas primeiras semanas de uso do Redcore Linux.

Nunca vi essa falha, nas 25 ou 30 distros que já instalei — nem mesmo, quando experimentei instalar o Dolphin em sessões Live de distros sem KDE.

Ferramenta "Mostrar dicas" do Dolphin, no KDE Neon

Imaginei compensar isso com a ferramenta "Mostrar dicas", que exibe uma miniatura e os dados da foto ou imagem — o que ainda não seria o ideal — mas esse recurso também estava ausente no Dolphin do Redcore Linux.

Dolphin com os módulos de pré-visualização de arquivos

Instalei os módulos de pré-visualização de arquivos no Dolphin — para os tipos de arquivo que utilizo* — mas isso não consertou o Dolphin (como, aliás, não era mesmo de se esperar).

* Deixei para mais tarde apenas o Marble, que deveria habilitar a pré-visualização de arquivos KML e KMZ — mas quando instalei (dias depois), não deu resultado. — Instalei até o kdegraphics-meta (para me certificar de que não faltasse nada), sem sucesso.

Dolphin no modo de visão em ícones

Tentei usar o modo de visão em Ícones, mas não consegui lidar com isso: — Nomes dispersos, em linhas quebradas — e um enorme desperdício de espaço.

Naturalmente, a vida continua — e completei 2 ou 3 semanas de uso contínuo do Redcore Linux — mas a vontade de reiniciar a máquina e carregar outra distro era uma constante.

Teste improvisado de USE flags no Redcore Linux

17 Jul 2022 - Depois de vários dias fora do Redcore (para esfriar a cabeça), pesquisei “dolphin gentoo panel” — e a solução apareceu logo no primeiro link, do Fórum do Gentoo: — Habilitar a flag (sinalizador) USE “semantic-desktop”.

Meus problemas estariam terminados, se eu já tivesse aprendido tudo sobre o Sisyphus, o Portage / emerge, flags USE etc. — Mas, como eu ainda não tinha lido quase nada sobre isso, improvisei uma solução capenga, só para testar. — Adicionei a flag num arquivo que diz expressamente “Não edite”, e apelei para um comando emerge achado em alguma página:

# cat /etc/portage/package.use/00-kde-apps.package.use | grep dolphin
kde-apps/dolphin thumbnail

     # This file has been automatically generated, do not edit.

     kde-apps/akonadi -mariadb
     kde-apps/ark zip
     kde-apps/dolphin thumbnail semantic-desktop
     kde-apps/k3b encode mad taglib
     kde-apps/kdecore-meta -webengine -webkit
     kde-apps/kdenetwork-meta dropbox -webengine
     kde-apps/kdesdk-meta -python
     kde-apps/krfb -wayland
     kde-apps/okular epub

# emerge --changed-use kde-apps/dolphin

Recompilação do Dolphin pelo emerge

A recompilação do Dolphin levou menos de 2 minutos.

Painel “Informações” (F11) no Dolphin do Redcore Linux

E voilà! — O Dolphin recompilado finalmente ofereceu a opção de exibir o painel “Informações” (F11) — com a pré-visualização de pastas e arquivos.

Opção “Mostrar dicas”, após recompilar o Dolphin

De brinde, o Dolphin recompilado também passou a oferecer a opção “Mostrar dicas” — que agora não é mais necessária.

Isso está longe de ser “o procedimento correto” — e talvez seja desfeito em alguma atualização, se o arquivo 00-kde-apps.package.use reverter ao padrão.

Mas foi o suficiente para comprovar que encontrei o caminho — e me deu a motivação prática que faltava para aprender mais sobre as flags USE.

Dolphin ainda sem dados Exif no Redcore Linux

Ainda falta solucionar a falta de dados Exif no painel “Informações” do Dolphin — mas isso é bem menos incômodo, no meu dia-a-dia.

Dados Exif no Gwenview do Redcore Linux

O KDE Plasma está habilitado, sim, a exibir os dados Exif. — No Gwenview, abrir seu painel lateral (F4) e clicar em “Show more details”. — Só falta levar essa capacidade para o Dolphin.

Flags USE

O arquivo de configuração do Portage que eu não devia ter editado

A maior dificuldade que deparei, para lidar com as flags USE, reside nas “dualidades” Redcore / Gentoo, e Portage / Sisyphus. — Aliás, a dualidade Portage (gerenciador de pacotes) / emerge (comando do Portage) também não ajuda o novato.

O Redcore tem pouquíssima documentação, pouquíssimos participantes no fórum, e não existe man sisyphus — só um sisyphus --help bem resumido.

É até compreensível que a Ajuda seja resumida — afinal, Sisyphus é feito, mesmo, para simplificar a vida do novato com o Portage / emerge — que ele usa (não substitui), quase como se ele fosse apenas uma coleção de alias simplificados para comandos emerge.

Só que toda a (ótima) documentação sobre as flags USE ensina a usar comandos emerge — e se refere à estrutura de arquivos de configuração no Gentoo. — Por isso, a cada passo, tive de tentar encontrar, no Redcore, os arquivos e comandos equivalentes aos indicados na documentação do Gentoo.

Redcore Wiki | Sisyphus

Gentoo Wiki | Handbook | USE flag Index | Forum

Além disso, a estrutura de arquivos de configuração do Gentoo pode ser alterada pelo usuário — sua própria documentação sugere isso — e os comandos indicados não são aplicáveis ao Redcore, sem adaptação:

Se package.use for pré-existente como um diretório (em oposição a um único arquivo), os pacotes podem ter seus sinalizadores USE modificados simplesmente criando arquivos no diretório package.use/

O importante é notar que existe uma ordem inversa de precedência — onde os últimos se sobrepõem aos anteriores — de modo que o usuário não precise editar os arquivos-padrão, pois valerá a personalização o que fizer mais adiante:

Configuração padrão de USE declarada nos arquivos make.defaults que fazem parte do seu perfil
Configuração USE definida pelo usuário em /etc/portage/make.conf
Configuração USE definida pelo usuário em /etc/portage/package.use
Configuração USE definida pelo usuário como variável de ambiente (temporária)

Porém, foi justamente ao editar o arquivo sugerido no item nº 3, que encontrei um aviso de “Não edite”, pois foi “gerado automaticamente”. — Uma adaptação introduzida pelo Redcore?

O arquivo de configuração do Sisyphus para o usuário editar

Só no final da pasta, descobri o caminho sugerido pelo Redcore: — um arquivo sisyphus-custom.package.use — na verdade, um link para onde ele realmente está, na estrutura de arquivos de configuração do Sisyphus.

Aliás, a própria pasta /etc/portage é um link para /opt/redcore-build/conf — onde estão as opções intel, arm, cross. — Um luxo!

# ls -o /etc/portage/package.use/ | grep 'kde\|custom'
-rw-r--r-- 1 root 336 Jul 22 15:04 00-kde-apps.package.use
-rw-r--r-- 1 root 336 Jul 18 12:16 00-kde-apps.package.use-CUSTOM
-rw-r--r-- 1 root 113 Jul 22 15:04 00-kde-frameworks.package.use
-rw-r--r-- 1 root 297 Jul 10 09:54 00-kde-plasma.package.use
lrwxrwxrwx 1 root  41 Oct 18  2021 10-sisyphus-custom.package.use -> /etc/sisyphus/sisyphus-custom.package.use

# ls -o /etc/portage
lrwxrwxrwx 1 root 38 Dec 19  2020 /etc/portage -> /opt/redcore-build/conf/intel/portage/

# ls -o /opt/redcore-build/conf
total 12
drwxr-xr-x 3 root 4096 Oct 18  2021 arm
drwxr-xr-x 3 root 4096 Oct 18  2021 cross
drwxr-xr-x 3 root 4096 Oct 18  2021 intel

# ls -o /etc/sisyphus/
total 12
lrwxrwxrwx 1 root   41 Jul 17 09:51 mirrors.conf -> /etc/sisyphus/sisyphus-mirrors-amd64.conf
-rw-r--r-- 1 root    0 Jul 14 07:34 sisyphus-custom.env.conf
-rw-r--r-- 1 root    0 Jul 14 07:34 sisyphus-custom.make.conf
-rw-r--r-- 1 root    0 Jul 14 07:34 sisyphus-custom.package.accept_keywords
-rw-r--r-- 1 root    0 Jul 14 07:34 sisyphus-custom.package.env
-rw-r--r-- 1 root    0 Jul 14 07:34 sisyphus-custom.package.license
-rw-r--r-- 1 root    0 Jul 14 07:34 sisyphus-custom.package.mask
-rw-r--r-- 1 root    0 Jul 14 07:34 sisyphus-custom.package.unmask
-rw-r--r-- 1 root  410 Jul 22 12:13 sisyphus-custom.package.use
-rw-r--r-- 1 root 1171 Oct 18  2021 sisyphus-mirrors-amd64.conf
-rw-r--r-- 1 root 1466 Jul 14 07:34 sisyphus-mirrors-arm64.conf

Fiquei sem saber o que colocar no arquivo sisyphus-custom.package.use — que veio vazio (nem 1 linha de dica!) — se seu “equivalente” no Handbook do Gentoo / Portage é uma pasta package.use/, com nada menos que 57 arquivos.

“Use a lógica!” — É tudo que um novato não deve fazer, pois ainda ignora a “lógica” de uma distro, com a qual falta se familiarizar. — Esta é a origem de 11 em cada 10 desastres.

Copiar para ele centenas de linhas, de dezenas de arquivos? — Transformá-lo numa pasta (como?) e povoá-la com dezenas de arquivos, imitando seu equivalente no Portage?

Experiências com o arquivo sisyphus-custom.package.use

Acabei me inspirando em um arquivo postado no Fórum Gentoo — feito para não ter de editar outros arquivos de configuração do Portage — e comecei a fazer minhas experiências:

# /etc/portage/package.use/10-sisyphus-custom.package.use
# links to:
# /etc/sisyphus/sisyphus-custom.package.use

######################## Global #########################

*/* semantic-desktop

*/* -nvidia radeonsi radeon amdgpu
*/* -cups
*/* -gnome-keyring
*/* -mysql
*/* -sqlite
*/* -wayland
*/* -samba

######################## Local ##########################

kde-apps/dolphin thumbnail semantic-desktop

Na primeira parte (Global), habilitam-se ou bloqueiam-se flags (sinalizadores) USE para todos os pacotes que possam usá-las. — Na segunda parte (Local), para pacotes específicos.

É redundante colocar semantic-desktop especificamente para o Dolphin — afinal, já habilitei globalmente — mas “o que não mata, engorda”, como dizia a minha avó.

Para aplicar as mudanças, executei o comando sisyphus upgrade --ebuild — em vez de algum comando emerge cheio de parâmetros e opções.

Mas antes, atualizei o sistema (para não misturar as coisas). — Em seguida, editei esse arquivo de configuração pessoal — e tornei a atualizar (verificando quais pacotes seriam afetados, antes de prosseguir).

Recompilação de pacotes após alterar flags USE no Redcore Linux

Na primeira experiência, habilitei globalmente */* semantic-desktop e desabilitei globalmente (hífen ou sinal negativo) */* -nvidia -cups -gnome-keyring -mysql -sqlite -wayland. — O comando sisyphus upgrade --ebuild propôs “mesclar” (merge) 35 pacotes — e o processo levou cerca de 3 horas 10 minutos (19:02 ~ 22:12), com uso de 100% de CPU a maior parte do tempo.

Duas semanas depois, minha atualização semanal se viu bloqueada, porque alguns pacotes exigiam as flags USE cups e sqlite. — Levei mais duas semanas para conseguir decifrar as mensagens de erro — e nesse meio tempo mais alguns pacotes já exigiam habilitar também a flag USE wayland:

!!! Multiple package instances within a single package slot have been pulled
!!! into the dependency graph, resulting in a slot conflict:
(...)
The following USE changes are necessary to proceed:
 (see "package.use" in the portage(5) man page for more details)
# required by kde-plasma/xdg-desktop-portal-kde-5.25.4::gentoo
# required by kde-plasma/plasma-meta-5.25.4::gentoo
# required by @selected
# required by @world (argument)
>=dev-qt/qtprintsupport-5.15.5-r1 cups                     ----- USE flags !!!
# required by kde-plasma/kwin-5.25.4-r1::gentoo
# required by kde-plasma/plasma-desktop-5.25.4::gentoo
# required by kde-plasma/plasma-meta-5.25.4::gentoo
# required by @selected
# required by @world (argument)
>=media-libs/mesa-22.1.5 wayland                           ----- USE flags !!!
# required by app-portage/sisyphus-4.2107.0-r5::redcore
# required by @selected
# required by @world (argument)
>=dev-lang/python-3.10.6 sqlite                            ----- USE flags !!!

Liberei de volta essas 3 flags USE — e finalmente consegui atualizar o sistema:

# /etc/portage/package.use/10-sisyphus-custom.package.use
# links to:
# /etc/sisyphus/sisyphus-custom.package.use

######################## Global #########################

*/* semantic-desktop

*/* -nvidia radeonsi radeon amdgpu
*/* -gnome-keyring
*/* -mysql
*/* -samba

######################## Local ##########################

kde-apps/dolphin thumbnail semantic-desktop

Redcore 2201

Versão anterior do Sisyphus, incapaz de processar tantos pacotes

Só em Outubro foi lançada a nova imagem ISO Redcore Linux Hardened 2201 (=2022 nº 1), com direito a Notas de lançamento, notícias nos portais, artigos nos blogs sobre “como instalar”, avaliações, comentários nos fóruns etc. — o que deve impulsionar novo aumento de cliques no ranking do Distrowatch ao longo das próximas semanas — mas por se tratar de uma distro rolling-release, não vi necessidade de fazer nova instalação.

O lançamento foi anunciado em 5 Outubro, após um curto período de "calmaria" (nenhuma atualização no Domingo anterior, 2 Outubro) — e no Domingo seguinte, 9 Outubro, o Sisyphus não conseguiu, sequer, processar a quantidade de pacotes a serem atualizados e suas dependências. — Rodou mais de 30 minutos, sem chegar a qualquer conclusão.

O Fórum do Redcore tem apenas um punhado de membros (o captcha, para se registrar, é desanimador!), e raríssimas postagens. — Talvez por isso, o Google falha vergonhosamente, quando se pesquisam palavras-chave dentro da "última semana". — Relendo as Notas de lançamento, intuí neste bugfix a possível solução:

bugfix: sisyphus não fica mais preso quando a lista de dependências é muito grande

Reinstalei então o sisyphus (versão atualizada):

# date; sisyphus install sisyphus --ebuild; date
Mon 10 Oct 09:58:53 -03 2022

These are the binary packages that would be merged, in order:

sys-apps/portage-3.0.38.1  app-portage/sisyphus-4.2209.1  app-portage/sisyphus-qt-4.2209.1

Total: 3 binary package(s)

Would you like to proceed? [y/N] y

(...)

Mon 10 Oct 10:00:49 -03 2022

Depois disso, o Sisyphus conseguiu processar todas as atualizações disponíveis, com todas as suas dependências: — Nada menos que 1481 pacotes binários + 12 ebuilds para compilar.

# date; sisyphus upgrade --ebuild; date
Mon 10 Oct 10:02:56 -03 2022

These are the binary packages that would be merged, in order:

sys-kernel/linux-headers-5.19
(...)
app-vim/gentoo-syntax-2

Total: 1481 binary package(s)

These are the source packages that would be merged, in order:

app-eselect/eselect-repository-13  www-client/links-2.28  gui-libs/libhandy-1.8.0  net-libs/webkit-gtk-2.36.7-r1  app-crypt/pinentry-1.2.1-r1  dev-vcs/git-2.38.0  media-video/ffmpeg-4.4.2  media-video/vlc-3.0.17.4-r1  kde-frameworks/baloo-5.98.0  sci-astronomy/kstars-3.6.1  kde-apps/dolphin-22.08.1  kde-plasma/plasma-workspace-5.25.5-r4

Total: 12 source package(s)

Would you like to proceed? [y/N] y
(...)
Mon 10 Oct 13:02:27 -03 2022

Essa atualização massiva levou 3 horas para ser baixada, compilada e instalada (das 10:02 às 13:02) — enquanto eu desempenhava minhas atividades normais na internet, ouvindo música, fazendo anotações, capturas de tela etc. — o que está dentro da experiência observada nesta máquina, ao longo dos últimos 4 meses.

No final, o Sisyphus apresentou 522 linhas de mensagens esotéricas — que copiei para meu arquivo de anotações, para eventuais consultas, no futuro — pois até o momento sou incapaz de compreender ou tirar proveito da maior parte.

Percebi que o arquivo /boot/grub/grub.cfg não tinha sido automaticamente atualizado — então tratei de atualizá-lo manualmente — para ser lido pelo Grub do openSUSE, que gerencia meu Menu de inicialização:

# date; grub2-mkconfig -o /boot/grub/grub.cfg; date
Mon 10 Oct 14:12:52 -03 2022
Generating grub configuration file ...
Found theme: /usr/share/grub/themes/redcore/theme.txt
Found linux image: /boot/vmlinuz-5.14.21-redcore
Found initrd image: /boot/initrd-5.14.21-redcore
done
Mon 10 Oct 14:12:58 -03 2022

Ao final dessa mega-atualização, nenhuma alteração nos aspectos "visíveis" a um usuário leigo. — O Kernel e o KDE Plasma permanecem nas mesmas versões de antes — o que parece prudente, para não complicar a tarefa dos mantenedores da distro. (Já vi outras distros agirem assim).

Pacotes da seção sys-kernel instalados no Redcore

É verdade que foi instalado um pacote linux-headers-5.19 — mas o único Kernel instalado e configurado, até agora, continua sendo o 5.14.21. — Sinal de que já tenho mais uma coisa para tentar aprender, e tomar as eventuais providências.

“There is NOT at least 6400 MiB disk space at...”

Sisyphus exige mais espaço em disco para o Redcore Linux

Apenas 4 meses depois de instalado, o Redcore Linux deixou de caber na partição de 30 GiB — apesar de eu “limpar” regularmente o cache de pacotes baixados e já instalados — dentro das possibilidades oferecidas pelas ferramentas de cada distro.

No Redcore Linux, a “simplicidade“ do Sisyphus oferece poucos recursos para isso — basicamente, # sisyphus autoremove — que na verdade, não limpa o cache, mas apenas remove pacotes deixados órfãos.

Por isso, preciso recorrer a comandos do emerge — que eu não queria explorar agora, para não complicar o aprendizado, nesta fase ainda inicial. — Por exemplo, o # emerge --depclean, ou o # eclean-dist -dv, e até mesmo o # emerge --update --newuse --deep --with-bdeps=y @world (que não é para isso, mas sempre ajuda a limpar um pouco).

Mas não tem jeito — o espaço ocupado em disco aumenta a cada semana, com uma rapidez que eu ainda não tinha visto em outras distros. — Tenho certeza de que há cada vez mais pacotes em cache ocupando espaço em disco, mas nunca encontrei um modo de eliminá-los, sem partir para a eliminação manual, peça por peça, “no olhômetro” e “no chutômetro” — ou seja, sem o risco de escangalhar o sistema por pura ignorância.

Finalmente, em 23 Outubro 2022, a atualização foi abortada por falta de espaço — com a mensagem de que “There is NOT at least 6400 MiB disk space at /var/tmp/portage/dev-lang/spidermonkey-91.13.0/temp”.

Eu já tinha driblado um problema semelhante no Manjaro simplesmente mudando o “Build directory” do AUR para uma pasta “ManjaroTemp” na partição de dados Warehouse (pertencente ao “Usuário comum”) — mas no Redcore eu teria de “inventar” meu próprio modo de fazer algo similar, sem a ajuda de um “Pamac-GUI” e sem ter encontrado na web nenhuma dica neste sentido. — A alternativa mais “simples” era simplesmente aumentar a partição do Redcore Linux, o que exigia “mover” a partição do MX Linux mais para o final, para abrir espaço no SSD (contíguo à partição do Redcore).

Deixei o assunto no quarto-dos-fundos da cabeça por algumas semanas — afinal, a imagem ISO de instalação, defasada em 8 meses, provou que ficar 15 ou 30 dias sem atualizar o Redcore não seria tão grave assim — mas nesse meio tempo outros 2 pacotes passaram a exigir ainda mais espaço, conforme sucessivas anotações, a cada tentativa de “limpeza” do cache de pacotes:

$ cat * | grep 'There is NOT at least'
 * There is NOT at least   6400 MiB   disk space at "/var/tmp/portage/dev-lang/spidermonkey-91.13.0/temp"
 * There is NOT at least   6400 MiB   disk space at "/var/tmp/portage/dev-lang/spidermonkey-91.13.0/temp"
 * There is NOT at least   6400 MiB   disk space at "/var/tmp/portage/dev-lang/spidermonkey-91.13.0/temp"
 * There is NOT at least   6400 MiB   disk space at "/var/tmp/portage/dev-lang/spidermonkey-91.13.0/temp"
 * There is NOT at least   6400 MiB   disk space at "/var/tmp/portage/dev-lang/spidermonkey-91.13.0/temp"
 * There is NOT at least   6400 MiB   disk space at "/var/tmp/portage/dev-lang/spidermonkey-91.13.0/temp"
 * There is NOT at least  15897 MiB   disk space at "/var/tmp/portage/dev-lang/rust-1.65.0/temp"
 * There is NOT at least      7 GiB   disk space at "/var/tmp/portage/dev-qt/qtwebengine-5.15.5_p20220618/temp"
 * There is NOT at least  15897 MiB   disk space at "/var/tmp/portage/dev-lang/rust-1.65.0/temp"
 * There is NOT at least      7 GiB   disk space at "/var/tmp/portage/dev-qt/qtwebengine-5.15.5_p20220618/temp"

E cada uma dessas tentativas significa uma “atualização abortada” — o que deixa sequelas, como acabei por descobrir.

Pasta na Memória RAM para compilações do Portage

Uma terceira alternativa que encontrei, seria criar uma pasta temporária na Memória RAM — mas como tenho apenas 1 pente de 16 GB, isto só serviria para agilizar compilações de, no máximo, 7 GB — pois eu teria de criar um “arquivo de exceções” para deixar de fora, por exemplo, os 15 GB necessários no caso do Rust (se é que preciso dele... mas isso já é uma outra estória: não encontrei uma resposta “para as massas”).

Aumentando a partição do Redcore, de 30 para 60 GiB

Para aumentar a partição do Redcore Linux (Linux11), copiei a partição do MX Linux (Linux12) para o espaço disponível depois dele — e deletei o original, deixando 30 GiB de espaço não-utilizado entre as duas distros. — Com isso, pude ampliar (grow) a partição do Redcore para 60 GiB.

Na noite de Domingo, 4 Dezembro 2022, finalmente consegui concluir a tão adiada atualização — ou, “quase concluir”. — Agora, a atualização não aborta mais por falta de espaço em disco (ufa!), mas... por outros motivos.

Em uma sequência de 5 execuções de # sisyphus upgrade --ebuild — alternando Restart, autoremove, comandos emerge — consegui alguns avanços parciais:

16:36 ~ 18:18   864 binary packages    11 source packages   "n" errors
                -- autoremove                               "n" errors
19:21 ~ 19:24                                               just install  -- Chrome 107
19:37 ~ 19:51   229 binary packages   155 source packages   "n" errors
19:54 ~ 21:47   385 binary packages    12 source packages   "n" errors    -- Chrome 108
21:58 ~ 22:22   166 binary packages    10 source packages   "n" errors
                162 binary packages    10 source packages   [y/N] No, sir!

Como eu precisava pesquisar no Google Chrome (e ele reclamava o tempo todo), acabei por reinstalar, e passou para a versão 107. — Após mais 2 tentativas de atualização geral, notei que o Chrome havia passado para a versão 108 — e outros pacotes também avançaram 2 versões, ao longo dessas tentativas.

Porém vários pacotes “atualizados” nunca entraram em vigor. — O Qt passou de 5.15.5 para 5.15.7, mas o resto do KDE, seus aplicativos e o Frameworks continuam nas versões anteriores a 23 Out. 2022 — apesar de inúmeros pacotes com versões mais novas terem sido baixados e (aparentemente) instalados.

Ao que parece, há muitos pacotes antigos que conflitam com as dependências exigidas — y otras cositas más.

Uma das mensagens mais interessantes é “Task was destroyed but it is pending”.

Em resumo, o Sisyphus quer, ou precisa, concluir uma série de tarefas que ficaram pendentes (de uma atualização abortada), mas aquelas “tarefas” foram deletadas.

\\\\

Por que não desistir?

Com 12 distros instaladas em “multiboot”, posso me dar ao luxo de insistir com algumas que ainda não domino — casos do Slackware, do Void e, agora, do Redcore — para aprender mais, nas horas vagas.

O Arch Linux, o Debian testing, o Mageia, o Manjaro e o MX Linux (Debian stable) oferecem todas as ferramentas de que preciso, a qualquer momento — em resumo: Google Chrome, GoogleEarth “Desktop”, WhatsChrome (enquanto não acaba), LibreOffice, Gimp, Foliate, VLC (ou outro), e uma penca de aplicativos KDE.

Não sou nenhum sabe-tudo; apenas, um usuário “médio, enxerido” — e já faz mais de 12 meses que acabo usando quase sempre o Arch Linux. — A essa altura do aprendizado, o Void me parece ser a próxima meta; e o Redcore, a meta seguinte.

Nesse quadro, acho mais importante “não quebrar de vez” o Redcore — ir devagar, pesquisar, ler, anotar tudo, voltar a ler, tentar de novo, com calma — do que ficar obcecado em resolver tudo de um dia para o outro, na base do “ou vai, ou racha”, sem ter, ainda, aprendido o suficiente para isso.

“Reinstalar” é o último recurso — pois significa desistir de entender, aprender e consertar a instalação.

Por que Redcore Linux?

Sabayon instalado (Dez. 2018 ~ Jan. 2020) no meu antigo PC desktop

Não sou "profissional de TI", mas apenas um usuário enxerido — e manter várias distros em dualboot (ou multiboot) é um modo de ter alternativas prontas para uso imediato, em caso de catástrofe local ou remota (*). — Para poder passar de uma distro a outra em 2 minutos e continuar trabalhando sem perda de tempo, uso sempre KDE e procuro aplicar sempre as mesmas configurações (incluindo um Conky mais informativo do que decorativo).

(*) Minha única “catástrofe” real, em 15 anos com Linux, ocorreu em 2017, e não foi só uma: foram duas, uma após outra. — Uma distro “de reserva” ficou meio bichada após um upgrade; e semanas depois deletei outra, por pura distração.— Desde então, já instalei umas 20 distros (até escolher as 12 atuais), sem nenhum outro desastre irreversível. Certa vez, perdi todo o KDE no Devuan, mas foi possível reverter. Agora, fiquei alguns dias sem conseguir carregar o MX Linux (mudou o UUID da partição!), mas também foi possível recuperá-lo. Coisas assim não são “desastres” de verdade.

Limitei minha coleção a 12 distros — atualmente, 2 do ramo Debian (Debian + MX Linux); 1 do sub-ramo Debian-Buntu (KDE Neon); 2 do ramo Arch (Arch + Manjaro); 2 do ramo Mandrake (PCLinuxOS + Mageia); além de openSUSE, Fedora, Slackware e Void, de seus próprios ramos da árvore Linux. — Isso permite me familiarizar, no dia-a-dia, com um leque amplo de distros, as mais diferentes umas das outras: empresariais ou comunitárias, mais completas ou mais enxutas, com diferentes abordagens, filosofias, gerenciadores de pacotes, sistemas init etc.

Em cada "ramo" da árvore Linux, procuro começar por uma distro mais amigável, para me familiarizar, e mais tarde avanço (ou não) para o mais complexo.

Foi mais ou menos o que fiz no caso do Arch Linux. Primeiro, instalei o Manjaro, no início de 2017 — e 6 meses depois instalei o Arch pelo Revenge (atual Zen Installer), para me familiarizar melhor. — Só 2 anos depois, enfrentei a instalação (em Bios-MBR, depois em UEFI-GPT), pelo "modo Arch", também conhecido como "modo BTW" ou "modo RTFM".

Com aquela experiência, me senti pronto para instalar o Void (em Bios-MBR, depois em UEFI-GPT), logo no outro mês. — O modo de instalação "construir peça por peça" tinha deixado de ser um bicho-de-7-cabeças, para mim (apesar de o Void não ter nada a ver com Arch!). — O instalador entregava o sistema básico, e bastava acrescentar o KDE Plasma.

Mas o Gentoo exige muito mais tempo e energia do que estou disposto a investir, por enquanto.

Comecei pelo Sabayon Linux, instalado no final de 2018 no meu antigo PC desktop, mas ele foi descontinuado pouco depois, em favor do Mocaccino OS — com o qual ainda não consegui me entender — e acabei escolhendo o Redcore Linux, em Junho 2021, para continuar experimentando uma distro do ramo Gentoo, antes de me arriscar (ou não!) no Gentoo propriamente dito.

Hits nas páginas do Distrowatch sobre as distros Gentoo-based

Redcore Linux era a distro do ramo Gentoo que parecia despertar mais interesse (na média dos 6 meses anteriores), entre os visitantes do Distrowatch, em Junho do ano passado. — Isto não significa maior ou menor número de usuários efetivos de uma distro mas, tão somente, maior ou menor número de acessos às páginas de cada distro no próprio Distrowatch — e isso flutua muito, aumentando logo após cada lançamento e diminuindo depois. O Redcore Linux 2101 (=2021 nº 1) tinha acabado de ser lançado, e é normal que mais pessoas clicassem na página do Distrowatch sobre a distro, para verificar mais detalhes. Em meados de 2022, passados 8 meses do último lançamento, baixou para o 107º lugar no ranking geral (média de acessos nos últimos 6 meses), e foi superada pelo CloudReady (que fez um lançamento há apenas 2 meses; mas não se destina a PC desktop).

Após o lançamento da imagem ISO Redcore 2201, em Outubro 2022, o interesse ou curiosidade levou a distro de novo ao 1º lugar entre as “Gentoo-based” (105º lugar no geral), na média dos 6 meses até o início de Dezembro.

Fora dessas flutuações sazonais, o ranking reflete cliques induzidos por milhares de usuários, que estão sempre elogiando ou recomendando distros em centenas de fóruns e blogs mais populares, no mundo inteiro — e o Redcore Linux tem se mantido nessa faixa de variação (sempre considerando a média dos 6 meses anteriores). — Por experiência pessoal de mais de 15 anos, tenho verificado que esse ranking acaba por refletir um "mix balanceado" das distros "mais faladas", com repositórios mais completos, maior número de usuários para ajudarem uns aos outros, fóruns mais ativos ou maior presença em outros fóruns, conserto mais rápido de eventuais bugs etc.

Neste momento (Junho 2022), as outras distros que mantenho instaladas estão em 1º, 4º, 7º, 8º, 11º, 14º, 15º, 17º, 32º, 39º e 51º lugares, e a meu ver isso corresponde mais ou menos às gradações daquele "mix" — nada muito difícil (ok, Gentoo está em 50º, mas exige muita compilação). — Tentar uma distro que oscila na faixa do 83º ao 107º lugar implica em estar disposto a enfrentar um pouco mais de dificuldade, em pelo menos alguns quesitos daquele "mix balanceado".

Mas esse ranking foi só 1 dos elementos que levei em consideração. — Eu já tinha pesquisado as demais distros do ramo Gentoo (além dele próprio), para avaliar qual poderia se adequar melhor ao meu projeto, e achei que Redcore era a que me atenderia. — Conversando com os colegas, recebi a indicação de um vídeo do Terminal Root, que confirmou minha avaliação.

Os colegas também indicaram o Funtoo, que me pareceu mais complicado para começar — e o Bentoo, que visa ser um Funtoo mais amigável, mas ainda está em desenvolvimento. — Outra opção seria o Calculate Linux, que estava logo após o Redcore, e eu provavelmente tentaria caso este não me atendesse.

Enfim, o Redcore Linux oferecia imagem ISO já com KDE Plasma — a única, por sinal, o que indicava ter seu foco neste ambiente, que é a minha preferência.

Download da ISO do Redcore Linux 2101 pelo wget

Naquela época, baixei a ISO Redcore Linux Hardened 2101 (=2021 nº 1), recém-lançada, verifiquei md5sum, sha256sum, "queimei" em DVD (para guardar) — mas não consegui completar o boot da sessão Live, por mais que tentasse. — Tive de resolver outras coisas mais urgentes, e acabei esquecendo do “ramo Gentoo”.

Só voltei àquele projeto no final do mês passado. Pesquisei mais um pouco, baixei e instalei o MocaccinoOS (muito fácil: nenhum problema) — mas depois não consegui atualizar, nem instalar nenhum pacote (erros do Luet ao acessar os repositórios, 2 dias seguidos; e quase sem resultados no Google), e concluí que não estou pronto para essa distro, ou ela ainda não está pronta para um "usuário comum" (mesmo que enxerido), como eu. — De fato, sua própria documentação (fraquíssima) alerta que continua "em andamento" (work in progress); e permanece até hoje na lista de espera do Distrowatch, desde Novembro 2020.

Infelizmente, minhas anotações e capturas de tela dos problemas com o Luet e seus repositórios estavam na pasta /home dele — que deletei sem pensar, depois de instalar o Redcore.

Enfim, baixei a ISO Redcore Linux Hardened 2102 (=2021 nº 2), lançada em Outubro 2021, verifiquei md5sum, sha256sum, "queimei" em DVD — o boot da sessão Live concluiu de imediato — e instalei com a maior facilidade, sem nenhum problema.

Após 6 meses de uso, continua atendendo ao meu objetivo de: — (1) Ser fácil para começar; e (2) Ser uma “porta de entrada” para me familiarizar, sem pressa, com o universo do Gentoo.

__________________________
Publicado inicialmente em 14 Junho 2022. — Atualizado até Dezembro 2022.

— … ≠ • ≠ … —

PC desktop UEFI / GPT

Linux, dualboot, discos, partições e backups

noreply@blogger.com (Mboaba) — Tue, 16 Nov 2021 20:36:00 +0000

Menu de inicialização de 12 distros Linus •

Isto não é um tutorial e não ensina nada. — É um registro para lembrar o que fiz, como fiz, e em quais datas (para localizar mais algum detalhe, se precisar).

É possível que essas anotações sejam úteis para outros usuários Linux — e neste caso vale observar alguns pontos:

1) Faço dualboot (ou multiboot) de várias distros — das mais diversas origens e características — escolhidas ao longo dos últimos 5 anos.

1.1) Todas as distros com KDE — e configurações tão iguais quanto possível.

2) Não salvo arquivos nas partições /home de cada distro. — No dia-a-dia, uso uma partição de dados (Warehouse, ex-Storage, ex-XTudo), acessível ao usuário-padrão UID=1000 — e outras mais específicas, para diferentes finalidades (Sites, Works, Depot1, Depot2).

3) No entanto, ao montar o atual PC desktop (2020), optei pelo início mais simples — só EFI + 12 partições-raiz + “Storage” — e deixei para adicionar outras partições mais tarde.

4) O hardware inicial:

Mobo:   ASUSTeK TUF B360M-PLUS Gaming/BR    UEFI / Sata III / USB 3.1 (Gen 1, 2)
CPU:    6 × Intel® Core™ i5-9400 CPU @ 2.90 GHz (min/max: 800/4100 MHz)
RAM:    16 GiB speed: 2400 MT/s type: DDR4   (max: 4 x 16 = 64 GiB)
iGPU:   Intel UHD Graphics 630 driver: i915 v: kernel
SSD:    480 GB Kingston A400 Sata III

5) Só faço backups das partições de dados — pois 12 distros já equivalem a vários backups do sistema operacional.

Índice

1) Primeiras semanas

2) Adicionando um velho HDD

3) Movendo 12 partições /home

4) Novo HDD de 1 TB

+) Como “mover” uma partição

1) Primeiras semanas

Hardware inicial: simplificado

10 Janeiro 2020 - Ao passar de um antigo hardware BIOS-MBR para um novo PC desktop UEFI-GPT, optei por começar do zero — placa-mãe e SSD Sata3 absolutamente intocados: — Nenhuma configuração alterada, nenhuma tabela de particionamento, nenhuma partição, nenhum sistema instalado antes, nenhum arquivo a preservar.

Particionamento do SSD interno

Criei a tabela de particionamento GPT, uma partição EFI + 12 partições-raiz, para até 12 distros Linux em dualboot (multiboot) — sem partição Swap e sem partições /home separadas.

No espaço que sobrou criei uma partição de dados “Storage”, para centralizar meus documentos, fotos, vídeos etc. — pois não faz sentido espalhar arquivos nas pastas /home de 12 distros.

Para começar, instalei 4 distros Linux em 2 dias — PCLinuxOS, openSUSE Tumbleweed, Fedora, KDE Neon — e tratei de me divertir com a nova máquina.

Remanejando antigas partições e convertendo HDDs de MBR para GPT

30 Janeiro 2020 - Afinal, pluguei no novo PC os HDDs e o SSD externo do antigo PC — alguns, bem velhinhos, mas ainda sem falhas — e todos ainda com particionamento MBR:

Device      Size    Year

   HDD    320 GB    2009     Sata II    Maxtor
   HDD    320 GB    2009     Sata II    Samsung
   HDD      1 TB    2016     Sata III   Seagate
   SSD      1 TB    2011     USB 2.0    Samsung

Descartando antigas partições, pelo GParted

Deletei partições que já não me interessavam (*), para abrir espaço em um dos antigos HDDs

(*) Descartei as partições-raiz, as partições /home e as partições Swap das 12 distros que eu tinha no antigo PC.

Realocando antigas partições, pelo GParted

Copiei, de um HDD, uma partição que eu queria preservar — colei no HDD onde eu tinha aberto um espaço — e fui repetindo o processo, até restarem só as partições de dados, e bastante espaço para movimentá-las:

Sites, Works - material publicado, ou reunido para publicação

XTudo -------- uso geral no dia-a-dia (2016-2019)

Armazem1 --- arquivos pouco utilizados + backups das outras partições

Armazem2 --- backup de Armazem1

A presença de partições "estendidas" indica que ambos os HDDs ainda estavam com suas antigas tabelas de particionamento MBR.

Conversão de um HDD, de MBR para GPT, pelo GParted

Com as partições a salvo em outro lugar, eu já podia converter um HDD, do particionamento MBR para GPT — basta "criar tabela de partição", e escolher GPT. — Em seguida, eu já podia trazer para ele as partições preservadas em outro lugar, e converter outro HDD.

Conversão de um disco SSD, de MBR para GPT, pelo GParted

Em seguida, converti de MBR para GPT o SSD externo (USB2).

Nele, deveria estar a partição Armazem2 — backup de Armazem1, que tentei copiar, mas vi que ia demorar muito. — O GParted começou estimando em 50 minutos, a uma velocidade de 128 MB/s; depois estimou em 1h30min, a 75 MB/s; depois, 2h20min a 42 MB/s; e por fim quase 7 horas, a 13 MB/s — e ainda demorou muito tempo para obedecer ao comando de cancelar.

Achei mais simples fazer isso mais tarde, depois de converter a tabela de particionamento.

Cópia do conteúdo de uma partição para outra (vazia) pelo Midnight Commander

Criei uma partição Depot2 no SSD externo (USB2) já convertido para GPT, e acabei optando por copiar para lá o conteúdo de Armazem1, pelo Midnight Commander, em modo root (preservando as propriedades de cada arquivo ou pasta). — Demorou quase 3 horas.

Comparação do conteúdo de 2 partições, pelo Dolphin

A cópia não foi perfeita — ficaram faltando 1 arquivo (em mais de 500 mil) e 4 pastas (em mais de 19,6 mil), ou cerca de 1 MiB (2,5 zilionésimos), até onde o Dolphin pôde apurar, sem privilégios.

Parece pouco — mas poderia ser algo da maior importância.

Pelo Krusader em modo root, seria fácil descobrir o que ficou faltando — mas não encontro qualquer registro de que eu tenha investigado o problema, naquele momento!

Distração ao pensar que estava convertendo um HDD para GPT

Intentei converter o HDD Seagate Sata3 de 1 TB, de MBR para GPT, mas por distração converti de MBR para MBR, mesmo — coisa que só percebi semanas depois. — Mas o ponto crítico é que, com isso, deletei para sempre qualquer possibilidade de descobrir e recuperar "1 arquivo e 4 pastas" (?) de Armazem1 que não foram copiados para Depot2.

ccc

Criei nele uma partição Depot1 e copiei de volta o conteúdo de Depot2, pelo Midnight Commander, em modo root. — Fui fazer outras coisas, aproveitei para dormir, e não sei quanto tempo demorou. — Pouco antes do amanhecer, vi que a cópia estava concluída.

Partições preservadas

Enfim, eu tinha preservado as partições que ainda me interessavam.

SSD + HDDs plugados no PC desktop

Fiquei, portanto, com 2 HDDs (sdb, sdc) no PC desktop — além do SSD principal (sda) — e o SSD externo USB2 (sdd), conectado para backup 1 vez por semana.

Esvaziei o terceiro HDD (Samsung 320 GB, Sata2), que recoloquei no antigo PC, ainda com particionamento MBR — pois sua placa-mãe de 2008 não sabe o que é GPT.

ccc

26 Fevereiro 2020 - Na seção de administração de usuários locais, o YaST2 oferece uma opção de mover a pasta pessoal para outra localização — e tentei verificar se isso incluiria movê-la para uma partição /home separada.

Para isso, faltava criar a partição de destino — e foi aí que percebi que eu não tinha realmente convertido o HDD 1TB (sdb) para GPT.

HDD 1 TB (sdb) finalmente convertido para GPT, pelo GParted

Converti o HDD de 1TB para GPT — com perda da partição Depot1. — Tornei a criar uma partição Depot1, vazia.

Criando partições no HDD 1TB, pelo GParted

Aproveitei para criar também 12 partições /home e uma partição Swap de 5,5 GiB.

Edição do fstab para montar a /home em uma partição separada

27 Fevereiro - A mudança da /home do Fedora para outra partição foi tumultuada — ocorreu alguma falha — e isso me fez tomar mais cuidado com as outras distros, mais tarde.

14:56 - Editei o arquivo /etc/fstab para montar a /home em uma partição separada (Home4, em sdb5). — Copiei a linha da /home de um antigo fstab do Fedora (sim, faço backups regulares desse arquivo), e apenas substituí o antigo UUID pelo atual.

Movendo a pasta pessoal para outra partição, pelo Midnight Commander

Para copiar a pasta /home/USER, ela precisava estar desmontada — por isso, fiz Logout como usuário — e Login em tty2 como Root.

Montei a partição Home4 pelo comando — # mount /dev/sdb5 /mnt — e movi a pasta de usuário para a partição “Home4”, pelo Midnight Commander.

O mais seguro seria apenas copiar, de modo a preservar o original, até me certificar de que a cópia estava 100% correta. — Também não precisava fazer isso “na unha”, por comandos em console virtual: — Bastava usar outra distro, com todo conforto do ambiente KDE, como fiz mais tarde.

Reiniciei o computador, para carregar o Fedora — agora, com a pasta pessoal na nova partição — e o boot não carregou a sessão KDE Plasma, nem o gerenciador de exibição SDDM.

Depois disso, perdi várias horas com tentativas sem rumo — em vez de examinar a situação, de modo racional.

19:28 - Só à noite, tentei Login como usuário em tty2, — e obtive uma pista significativa:

-- flavio: /home/flavio: change directory failed: Permission denied
Logging in with home = "/"

Pesquisando essa pista no Google, descobri o comando: — # restorecon -Rv /home — que resolveu o problema:

NAME
       restorecon - restore file(s) default SELinux security contexts.
...
DESCRIPTION
...
       This program is primarily used to set the security context (extended attributes) on one or more files.
...
       -R, -r change files and directories file labels recursively (descend directories).

       -v     show changes in file labels. Multiple -v options increase the verbosity. Note that the -v and -p options
              are mutually exclusive.

Ao carregar o KDE Plasma, descobri que o Auto-Login tinha sido desabilitado

19:54 - Finalmente, consegui carregar uma sessão KDE Plasma, — e descobri que o Login automático de usuário estava desabilitado. — Tornei a configurar, e tudo se normalizou.

ccc

Copiei do antigo fstab também a linha referente ao Swap — substituí o identificador UUID pelo atual — e ativei pelo comando # swapon --all.

O uso “negativo” de Memória RAM era um bug daquela versão do Conky.

A mudança da /home do openSUSE, do KDE Neon e do PCLinuxOS para partições separadas não apresentou maiores novidades, e está resumida no relato da migração para o novo PC desktop.

\\\\

26 Fevereiro ~ 8 Março - Movi as pastas /home para as respectivas partições separadas e habilitei a partição Swap nas 4 distros Linux já instaladas.

7 Março 2020 - Configurei o Luckybackup para trabalhar com as novas partições de origem e de destino.

2020-03-07 ─── Luckybackup

Profiles:

1) Depot1 --> Depot2
os
Depot1                             Depot2
   └── Backup              ───>       ├──
   ├── Distros Linux       ───>       ├──
   ├── Sites_backups       ───>       ├──
   ├── Colab               ───>       ├──
   ├── Fotos digitais      ───>       ├──
   ├── Downloads           ───>       ├──
   ├── Biblioteca          ───>       ├──
   └── AutoCAD, Corel      ───>       └──


2) Partitions --> Depot1

                            Depot1
                               └── Backup
Storage         ───>                  ├──
Xtudo           ───>                  ├──
Works           ───>                  ├──
Sites           ───>                  └──

O resultado dessa movimentação pode ser resumida comparando o antes e o depois:

sda       447 GiB   -----> SSD 480 GB Sata3      sda       447 GiB   -----> SSD 480 GB Sata3
├─sda1      2 GiB   efi                           ├─sda1      2 GiB   efi
├─sda2     50 GiB   Linux1                       ├─sda2     50 GiB   Linux1
├─sda3     30 GiB                                ├─sda3     30 GiB
├─sda4     30 GiB                                ├─sda4     30 GiB
├─sda5     30 GiB   Linux4                       ├─sda5     30 GiB   Linux4
├─sda6     30 GiB   Linux5                       ├─sda6     30 GiB   Linux5
├─sda7     30 GiB   Linux6                       ├─sda7     30 GiB   Linux6
├─sda8     30 GiB                                ├─sda8     30 GiB
├─sda9     30 GiB                                ├─sda9     30 GiB
├─sda10    30 GiB                                ├─sda10    30 GiB
├─sda11    30 GiB                                ├─sda11    30 GiB
├─sda12    30 GiB                                ├─sda12    30 GiB
├─sda13    30 GiB                                ├─sda13    30 GiB
└─sda14    65 GiB   Storage                      └─sda14    65 GiB   Storage

                                                 sdb       931 GiB   -----> HDD   1 TB Sata3
                                                 ├─sdb1    770 GiB   Depot1
                                                 ├─sdb2     13 GiB   Home1
                                                 ├─sdb3     13 GiB
                                                 ├─sdb4     13 GiB
                                                 ├─sdb5     13 GiB   Home4
                                                 ├─sdb6     13 GiB   Home5
                                                 ├─sdb7     13 GiB   Home6
                                                 ├─sdb8     13 GiB
                                                 ├─sdb9     13 GiB
                                                 ├─sdb10    13 GiB
                                                 ├─sdb11    13 GiB
                                                 ├─sdb12    13 GiB
                                                 ├─sdb13    13 GiB
                                                 └─sdb14     5 GiB   Swap

                                                 sdc       298 GiB   -----> HDD 320 GB Sata2
                                                 ├─sdc1    150 GiB   XTudo
                                                 ├─sdc2    130 GiB   Works
                                                 └─sdc3     18 GiB   Sites

                                                 sdd       931 GiB   -----> SSD   1 TB  USB2
                                                 └─sdd1    769 GiB   Depot2

Essas operações [item 1, até aqui] foram sintetizadas no relato da transição para um novo hardware UEFI-GPT.

2) Adicionando um velho HDD

Adicionando o último dos antigos HDDs

10 Janeiro 2021 - Um dos velhos HDDs de 320 GB ainda estava fora de uso — quando descobri um espaço no chassi do novo PC, onde poderia fixá-lo.

Criei nele uma partição “Warehouse” — para substituir a partição “Storage”, que já estava ficando cheia — e movi seu conteúdo para lá:

sda       447 GiB   -----> SSD 480 GB Sata3      sda       447 GiB   -----> SSD 480 GB Sata3
├─sda1      2 GiB   efi                          ├─sda1      2 GiB   efi
├─sda2     50 GiB   Linux1                       ├─sda2     50 GiB   Linux1
├─sda3     30 GiB                                ├─sda3     30 GiB   Linux2
├─sda4     30 GiB                                ├─sda4     30 GiB   Linux3
├─sda5     30 GiB   Linux4                       ├─sda5     30 GiB   Linux4
├─sda6     30 GiB   Linux5                       ├─sda6     30 GiB   Linux5
├─sda7     30 GiB   Linux6                       ├─sda7     30 GiB   Linux6
├─sda8     30 GiB                                ├─sda8     30 GiB   Linux7
├─sda9     30 GiB                                ├─sda9     30 GiB   Linux8
├─sda10    30 GiB                                ├─sda10    30 GiB   Linux9
├─sda11    30 GiB                                ├─sda11    30 GiB   Linux10
├─sda12    30 GiB                                ├─sda12    30 GiB   Linux11
├─sda13    30 GiB                                └─sda13    30 GiB   Linux12
└─sda14    65 GiB   Storage
                                                 
sdb       931 GiB   -----> HDD   1 TB Sata3      sdb       931 GiB   -----> HDD   1 TB Sata3
├─sdb1    770 GiB   Depot1                       ├─sdb1    770 GiB   Depot1
├─sdb2     13 GiB                                ├─sdb2     13 GiB   Home1
├─sdb3     13 GiB                                ├─sdb3     13 GiB   Home2
├─sdb4     13 GiB                                ├─sdb4     13 GiB   Home3
├─sdb5     13 GiB                                ├─sdb5     13 GiB   Home4
├─sdb6     13 GiB                                ├─sdb6     13 GiB   Home5
├─sdb7     13 GiB                                ├─sdb7     13 GiB   Home6
├─sdb8     13 GiB                                ├─sdb8     13 GiB   Home7
├─sdb9     13 GiB                                ├─sdb9     13 GiB   Home8
├─sdb10    13 GiB                                ├─sdb10    13 GiB   Home9
├─sdb11    13 GiB                                ├─sdb11    13 GiB   Home10
├─sdb12    13 GiB                                ├─sdb12    13 GiB   Home11
├─sdb13    13 GiB                                ├─sdb13    13 GiB   Home12
└─sdb14     5 GiB   Swap                         └─sdb14     5 GiB   Swap
                                                 
sdc       298 GiB   -----> HDD 320 GB Sata2      sdc       298 GiB   -----> HDD 320 GB Sata2
├─sdc1    150 GiB   XTudo                        ├─sdc1    150 GiB   XTudo
├─sdc2    130 GiB   Works                        ├─sdc2    130 GiB   Works
└─sdc3     18 GiB   Sites                        └─sdc3     18 GiB   Sites
                                                 
sdd       931 GiB   -----> SSD   1 TB  USB2      sdd       298 GiB   -----> HDD 320 GB Sata2
└─sdd1    769 GiB   Depot2                       └─sdd1    240 GiB   Warehouse
                                                 
                                                 sde       931 GiB   -----> SSD   1 TB  USB2
                                                 └─sde1    769 GiB   Depot2

Com isso, eliminei a partição “Storage” — e ficaram 65 GiB livres no SSD interno Sata3.

Local Storage:                total:    2.84 TiB          used: 838.23 GiB   (28.8%)

  Sata #1   ID-1: /dev/sda   SSD  Sata3  Kingston  SA400S37480G        447.13 GiB   480 GB
  Sata #3   ID-2: /dev/sdb   HDD  Sata3  Seagate   ST1000DM003-1SB102  931.51 GiB     1 TB  (2016)
  Sata #4   ID-3: /dev/sdc   HDD  Sata2  Maxtor    STM3320613AS        298.09 GiB   320 GB  (2008)
  Sata #5   ID-4: /dev/sdd   HDD  Sata2  Samsung   HD322HJ             298.09 GiB   320 GB  (2008)
  USB ext   ID-5: /dev/sde   SSD  USB2   Samsung   S2 Portable         931.51 GiB     1 TB  (2011)

Optical-1: /dev/sr0   DRW  Sata3  ASUS      DRW-24F1MT

Essas movimentações (acima) foram detalhadas em Adicionando HDD a 11 distros Linux em dualboot.

3) Movendo 12 partições /home

Espaço necessário para as 12 partições /home

19 Maio 2021 - Acabei amadurecendo algumas ideias para redistribuir melhor as partições existentes — enquanto me preparava para comprar um HDD maior e / ou mais um SSD:

Eliminar a partição “XTudo” — após mover seu conteúdo para uma pasta na partição “Depot1” que é espelhada na partição “Depot2” (backup);

Mover as partições /home para um dos HDDs mais antigos — provisoriamente;

Aumentar as partições “Depot1” e “Depot2”, de 770 para 931 GiB;

Aumentar a partição “Warehouse”, de 240 GiB para 298 GiB;

Mover e aumentar a partição “Swap”, de 5,5 GiB para 10,09 GiB;

Reduzir a partição “Sites”, de 18 GiB para 12 GiB;

Reduzir a partição “Works”, de 130 GiB para 120 GiB.

O ponto de partida foi o cálculo do espaço ocupado pelas 12 partições /home. — Os demais números foram ajustados em função disso (e do tamanho dos HDDs), ao longo do processo.

Em resumo:

sda       447 GiB   -----> SSD 480 GB Sata3      sda       447 GiB   -----> SSD 480 GB Sata3
├─sda1      2 GiB   efi                           ├─sda1      2 GiB   efi
├─sda2     50 GiB   Linux1                       ├─sda2     50 GiB   Linux1
├─sda3     30 GiB   Linux2                       ├─sda3     30 GiB   Linux2
├─sda4     30 GiB   Linux3                       ├─sda4     30 GiB   Linux3
├─sda5     30 GiB   Linux4                       ├─sda5     30 GiB   Linux4
├─sda6     30 GiB   Linux5                       ├─sda6     30 GiB   Linux5
├─sda7     30 GiB   Linux6                       ├─sda7     30 GiB   Linux6
├─sda8     30 GiB   Linux7                       ├─sda8     30 GiB   Linux7
├─sda9     30 GiB   Linux8                       ├─sda9     30 GiB   Linux8
├─sda10    30 GiB   Linux9                       ├─sda10    30 GiB   Linux9
├─sda11    30 GiB   Linux10                      ├─sda11    30 GiB   Linux10
├─sda12    30 GiB   Linux11                      ├─sda12    30 GiB   Linux11
└─sda13    30 GiB   Linux12                      └─sda13    30 GiB   Linux12

sdb       931 GiB   -----> HDD   1 TB Sata3      sdb       931 GiB   -----> HDD   1 TB Sata3
├─sdb1    770 GiB   Depot1                       └─sdb1    931 GiB   Depot
├─sdb2     13 GiB   Home1
├─sdb3     13 GiB   Home2                        sdc       298 GiB   -----> HDD 320 GB Sata2
├─sdb4     13 GiB   Home3                        ├─sdc1     12 GiB   Sites
├─sdb5     13 GiB   Home4                        ├─sdc2     13 GiB   Home1
├─sdb6     13 GiB   Home5                        ├─sdc3     13 GiB   Home2
├─sdb7     13 GiB   Home6                        ├─sdc4     13 GiB   Home3
├─sdb8     13 GiB   Home7                        ├─sdc5     13 GiB   Home4
├─sdb9     13 GiB   Home8                        ├─sdc6     13 GiB   Home5
├─sdb10    13 GiB   Home9                        ├─sdc7     13 GiB   Home6
├─sdb11    13 GiB   Home10                       ├─sdc8     13 GiB   Home7
├─sdb12    13 GiB   Home11                       ├─sdc9     13 GiB   Home8
├─sdb13    13 GiB   Home12                       ├─sdc10    13 GiB   Home9
└─sdb14     5 GiB   Swap                         ├─sdc11    13 GiB   Home10
                                                 ├─sdc12    13 GiB   Home11
sdc       298 GiB   -----> HDD 320 GB Sata2      ├─sdc13    13 GiB   Home12
├─sdc1    150 GiB   XTudo                        ├─sdc14   120 GiB   Works
├─sdc2    130 GiB   Works                        └─sdc15    10 GiB   Swap
└─sdc3     18 GiB   Sites
                                                 sdd       298 GiB   -----> HDD 320 GB Sata2
sdd       298 GiB   -----> HDD 320 GB Sata2      └─sdd1    298 GiB   Warehouse
└─sdd1    240 GiB   Warehouse
                                                 sde       931 GiB   -----> SSD   1 TB  USB2
sde       931 GiB   -----> SSD   1 TB  USB2      └─sde1    931 GiB   Depot2
└─sde1    769 GiB   Depot2

Backup dos arquivos fstab e resumo da montagem das 12 partições /home

Fiz um backup atualizado dos arquivos fstab de todas as distros — e um extrato das linhas referentes às respectivas partições /home.

Transformando o backup de XTudo em uma pasta permanente

Em seguida tentei mover XTudo dentro da partição Depot1 — afinal, todo o conteúdo da partição XTudo já estava lá, na pasta de Backups — e bastaria tirá-la de lá.

A vantagem disso é que "mover" uma pasta e seus arquivos, dentro de uma partição, não exige mudá-los realmente de lugar — como ocorreria ao enviar 82.6 GiB para outro HDD — mas, "apenas", alterar os caminhos (paths) associados a seus nomes.

Minha expectativa era de que isso tomasse muito menos tempo do que apagar a pasta Depot1/Backup/XTudo — e depois copiar toda a partição XTudo para uma nova pasta Depot1/XTudo.

Não foi tão simples assim. — Descobri que eu não tinha permissão de escrita, para criar uma pasta na raiz de Depot1 (só dentro das pastas já existentes) — nem para deletar (mover) milhares de arquivos que vim acumulando desde 1990 (*), ainda em disketes MS-DOS (16 bits), passando por partições Fat32, NTFS, exFat, discos ZIP, CDs e DVDs (real-only até para o root!), antes de chegarem ao ext4 (2016).

(*) Não pude preservar os arquivos do Apple II+ 8 bits (1986-1990), pois quando comprei meu primeiro PC-XT não encontrei mais quem ainda tivesse hardware e software para fazer aquela transferência.

Mesmo depois de 2016, ainda pratiquei muitas bobagens — p.ex.: copiar arquivos de sistema (como root) em XTudo — e o uso do Luckybackup em modo root ocultava esses problemas.

Redução de XTudo entre 19 e 23 Maio

Mas nada disso estava claro, quando comecei essa reorganização. — Apenas "mover" a pasta XTudo dentro da partição Depot1, me tomou o resto do dia 19 Maio, algumas horas no dia 22, e boa parte do dia 23 (*), consertando arquivos read-only, alterando permissões e aproveitando para deletar toneladas de coisas inúteis. — Ao eliminar arquivos inúteis, XTudo diminuiu de 83,2 GiB (176.550 arquivos em 6.035 pastas) para 82,6 GiB (170.281 arquivos em 5.241 pastas), com a certeza de não ter apagado nada de importante.

(*) Sim, mantive-me afastado do problema nos dias 20 e 21. — Tratei de me divertir e esfriar a cabeça, antes de voltar a ele.

Ainda ficaram vários problemas, que só fui resolver em Setembro, quando finalmente substituí o Luckybackup em modo root por comandos rsync em modo usuário.

Por fim, repeti o processo dentro da partição Depot2 — também para evitar uma transferência de 82,6 GiB entre discos diferentes.

Obs.: - Isto é um resumo bastante simplificado, para me guiar nos meandros da memória, e talvez eu tenha cometido algum erro nos detalhes. — Se for preciso, "basta" eu examinar melhor os 1.775 arquivos guardados na subpasta Particionamento, que documentam as operações abrangidas neste registro (2021) — e se for o caso, volto para corrigi-los:

$ tree /Warehouse/Byteria/Particionamento/ -d

                ├── 2021-01-10_add-HDD-320GB
                ├── 2021-05-23_re-Partitioning
                │   └── MX-Live
                ├── 2021-07_a_09-rsync-SMART-status
                │   ├── 2021-07-09_GSmartControl
                │   ├── 2021-09-05_16-00_Live-Slackware-PIFFFFF
                │   ├── 2021-09-05_16-30_Live-Mageia
                │   ├── 2021-09-08_09-30_14-25_Live-PCLinuxOS
                │   ├── 2021-09---jpg
                │   ├── Luckybackup
                │   │   ├── 2021-05-19_Luckybackup-logs
                │   │   │   └── Luckybackup-logs
                │   │   ├── 2021-09-04_a_Luckybackup-logs
                │   │   └── 2021-09-04_b_Luckybackup-logs
                │   └── rsync_scripts_2021-11-01
                ├── 2021-11-12_new-HDD-1TB
                │   ...
                │   ├── 2021-11-12
                │   ├── 2021-11-14
                │   ...
                │   ├── Gimp
                │   ├── Photos
                │   ├── PrtScn
                │   ...
                ├── blkid
                ├── etc-fstab
                │   ├── 2020
                │   │   ├── 2020-03-01
                │   │   ├── 2020-03-07
                │   │   ...
                │   │   └── 2020-09-27
                │   ├── 2021-01-11_a
                │   ├── 2021-01-11_b
                │   ├── 2021-05-02
                │   ├── 2021-05-19
                │   ...
                │   ├── 2021-10-03-a
                │   ├── 2021-10-10-a
                │   └── bash_cp-etc-fstab
                └── x_Old

Eliminado XTudo das tarefas do Luckybackup

23 Maio - Eliminei do Luckybackup a "tarefa XTudo" e executei um backup geral.

Luckybackup Profiles:

1) Depot1 --> Depot2

Depot1                             Depot2
   └── Backup              ───>       ├── Backup
   ...
   ├── AutoCAD, Corel      ───>       ├── AutoCAD, Corel
   └── XTTudo              ───>       └── XTudo

2) Partitions --> Depot1

                            Depot1
                               └── Backup
Storage         ───>                  ├── Storage
Xtudo                                 │
Works           ───>                  ├── Works
Sites           ───>                  └── Sites

Desmontando e deletando a partição XTudo

Pelo GParted, desmontei e deletei a partição XTudo (sdc1).

Desmontando uma partição, para expandi-la pelo GParted

Ainda pelo GParted, desmontei Warehouse (sdd1) e expandi para ocupar todo o HDD. — Aproveitei para eliminar XTudo do Conky2.

Criando partições pelo GParted em Live MX Linux

Como iria mover (copiar e colar) muitas partições, baixei uma ISO atualizada do MX Linux 19.4 KDE e iniciei uma sessão Live — com todas as partições desmontadas.

Instalei o GParted, configurei o Conky, o hddtemp, o KDE Spectacle e mais algumas coisas, para trabalhar na sessão Live por várias horas.

Sempre me arrependo, quando não instalo o gnome-screenshot, muito mais prático para capturar menus de contexto — por exemplo: copiar e colar partições pelo GParted. — Ver Como “mover“ uma partição, adiante.

Copiando partições do HDD e colando no SSD externo (USB2)

Pelo GParted, criei partições de 130 GiB e de 18 GiB no SSD externo (USB2), copiei as partições Works e Sites do HDD (sdc2, sdc3), e colei nelas. — A taxa de leitura e gravação (Disk I/O) ficou em torno de 80 ~ 82 MiB/s.

Redução (shrink) da partição pelo GParted

Diminuí (shrink) a cópia da partição Works, de 130 GiB para 120 GiB; e a cópia da partição Sites, de 18 GiB para 12 GiB.

Copiando e colando partições no HDD, pelo GParted

Deletei as partições originais Works, Sites (sdc2, sdc3), e fiquei com esse HDD vazio, pronto para o passo seguinte da minha reorganização de partições:

sdc1 - Colei de volta a partição Sites, agora com 12 GiB

sdc2 - Criei uma partição XFS, para mais tarde colar a /home do openSUSE

sdc3 ~ sdc13 - Colei no espaço não-alocado as outras 11 partições /home

sdc14 - Colei de volta a partição Works, agora com 120 GiB

Restou um espaço não-alocado de 10,09 GiB

Deletando cópias já utilizadas e expandindo a partição Depot2

No SSD externo (USB2), deletei as cópias intermediárias de Works, Sites, que não eram mais necessárias — e expandi (grow) a partição Depot2 para ocupar todo o espaço.

Expandindo a partição Swap pelo GParted

Desmontei e copiei a partição Swap (sdb14) — colei em outro HDD (sdc15) — e em seguida expandi (grow) de 5,5 GiB para 10,09 GiB.

Ao copiar e colar a partição Swap (em vez de criar outra), preservei o identificador UUID — assim, não preciso editar os arquivos /etc/fstab das 12 distros.

O rótulo (label) "Swap" se perdeu no caminho, e tive de aplicar de novo — pois optei por usá-lo no fstab do Slackware. — De qualquer modo, sempre me ajuda a identificar.

Eliminando partições já copiadas para outros locais, no GParted

No HDD maior, deletei as partições Home2 ~ Home12 (sdb3 ~ sdb13) — e em seguida a antiga partição Swap de 5,5 GiB (sdb14) — que não eram mais necessárias.

Opções escolhidas no Clonezilla para copiar a partição XFS

Para lidar com a partição /home em XFS do openSUSE, baixei uma ISO atualizada do Clonezilla, e iniciei a sessão Live pela 2ª opção (carregar para a RAM).

Em seguida, selecionei a opção de cópia local device-device, aceitei as opções-padrão (modo iniciante) e partição-partição (local).

Escolha da partição de destino no Clonezilla

Escolhi a partição sdb2 como origem (source) e a partição sdc2 como destino (target).

Opção padrão de não verificar ou consertar a partição de origem

Escolhi a opção sfsck.(Skip checking / repairing source file system), pois meu objetivo era, mesmo, apenas copiar a partição XFS da /home do openSUSE.

Avisos tenebrosos do Clonezilla

Antes de prosseguir, o Clonezilla mostra uma lista enorme, com todas as partições do HDD de destino, gritando que todos os dados serão perdidos. — Fique calmo, e observe lá no final da linha, que o aviso alarmante se refere só à partição sdc2. — Você diz que sim, e o Clonezilla insiste em tocar o terror, mais uma vez.

Barra de progresso do Clonezilla

Enfim, a clonagem foi um sucesso total.

Teste de funcionamento da nova /home do openSUSE

Para testar a nova partição /home (sdc2) do openSUSE, despluguei o HDD onde ainda estava a partição original (sdb2). — Não mugiu nem miou. — Aprovado.

Deletando a antiga partição pelo GParted em sessão Live

Em nova sessão Live do MX Linux, deletei a antiga partição /home do openSUSE.

Expandindo a partição para ocupar todo o HDD, pelo GParted

Expandi a partição Depot1 para ocupar todo o HDD.

Montagem manual das partições, pelo Dolphin

Em todas as distros, a montagem automática de partições adicionais pelo uDisks2 apresenta falhas no primeiro boot após esses remanejamentos. — Em geral, basta montar 1 vez as partições que faltam. — Isso pode ser feito manualmente, pelo Dolphin.

Esquecer os dispositivos não mais encontrados

Aproveito e mando o KDE "esquecer" os dispositivos "desconectados" — Eles não existem mais.

Comendando a linha da partição XTudo no fstab do Debian

Antes de carregar o Debian, desabilitei no seu fstab a linha da extinta partição XTudo — caso contrário, eu teria de enfrentar um problema durante o boot, a ser resolvido por “comandos em tela preta“.

Este é um dos motivos pelos quais evito usar o fstab para montagem de partições adicionais: — Falta de flexibilidade e exigência de reparos em ambiente não-amigável. — A montagem automática pelo KDE Plasma (usando Udisks2) é muito mais confortável, em todas as situações imagináveis.

4) Novo HDD de 1 TB

Substituição dos velhos HDDs Sata2 e reordenamento do DRW

12 Novembro 2021 - Finalmente, comprei um HDD 1 TB novo, para aposentar de vez os 2 HDDs 320 GB Sata2.

sda       447 GiB   -----> SSD 480 GB Sata3      sda     447.1 GIB   -----> SSD 480 GB Sata3
├─sda1      2 GiB   efi                          ├─sda1      2 GIB   efi
├─sda2     50 GiB   Linux1                       ├─sda2     50 GIB   Linux1
├─sda3     30 GiB   Linux2                       ├─sda3     30 GIB   Linux2
├─sda4     30 GiB   Linux3                       ├─sda4     30 GIB   Linux3
├─sda5     30 GiB   Linux4                       ├─sda5     30 GIB   Linux4
├─sda6     30 GiB   Linux5                       ├─sda6     30 GIB   Linux5
├─sda7     30 GiB   Linux6                       ├─sda7     30 GIB   Linux6
├─sda8     30 GiB   Linux7                       ├─sda8     30 GIB   Linux7
├─sda9     30 GiB   Linux8                       ├─sda9     30 GIB   Linux8
├─sda10    30 GiB   Linux9                       ├─sda10    30 GIB   Linux9
├─sda11    30 GiB   Linux10                      ├─sda11    30 GIB   Linux10
├─sda12    30 GiB   Linux11                      ├─sda12    30 GIB   Linux11
└─sda13    30 GiB   Linux12                      └─sda13    30 GIB   Linux12

sdb       931 GiB   -----> HDD   1 TB Sata3      sdb       931 GIB   -----> HDD   1 TB Sata3
└─sdb1    931 GiB   Depot1                       ├─sdb1     12 GIB   Sites
                                                 ├─sdb2     15 GIB   Home1
sdc       298 GiB   -----> HDD 320 GB Sata2      ├─sdb3     15 GIB   Home2
├─sdc1     12 GiB   Sites                        ├─sdb4     15 GIB   Home3
├─sdc2     13 GiB   Home1                        ├─sdb5     15 GIB   Home4
├─sdc3     13 GiB   Home2                        ├─sdb6     15 GIB   Home5
├─sdc4     13 GiB   Home3                        ├─sdb7     15 GIB   Home6
├─sdc5     13 GiB   Home4                        ├─sdb8     15 GIB   Home7
├─sdc6     13 GiB   Home5                        ├─sdb9     15 GIB   Home8
├─sdc7     13 GiB   Home6                        ├─sdb10    15 GIB   Home9
├─sdc8     13 GiB   Home7                        ├─sdb11    15 GIB   Home10
├─sdc9     13 GiB   Home8                        ├─sdb12    15 GIB   Home11
├─sdc10    13 GiB   Home9                        ├─sdb13    15 GIB   Home12
├─sdc11    13 GiB   Home10                       ├─sdb14   609 GIB   Warehouse
├─sdc12    13 GiB   Home11                       ├─sdb15   120 GIB   Works
├─sdc13    13 GiB   Home12                       └─sdb16    10 GIB   Swap
├─sdc14   120 GiB   Works
└─sdc15    10 GiB   Swap                         sdc       931 GIB   -----> HDD   1 TB Sata3
                                                 └─sdc1    931 GIB   Depot1
sdd       298 GiB   -----> HDD 320 GB Sata2
└─sdd1    298 GiB   Warehouse                    sdd       931 GIB   -----> SSD   1 TB  USB2
                                                 └─sdd1    931 GIB   Depot2
sde       931 GiB   -----> SSD   1 TB  USB2
└─sde1    769 GiB   Depot2

Aumentei “Warehouse”, de 298 GiB para 609 GiB — e as partições /home, de 13 para 15 GiB.

A partição “Depot1” permaneceu no mesmo HDD. — Apenas, coloquei o novo HDD 1 TB “antes“ dele — em lugar do DRW, que passei para o último conector Sata3.

Local Storage:      total: 3.17 TiB        used: 1.29 TiB  (40.8%)

Sata #1  /dev/sda   Kingston SA400S37480G  447.13 GiB  6.0 Gb/s SSD            28ºC  GPT
Sata #2  /dev/sdb   Seagate  ST1000DM010   931.51 GiB  6.0 Gb/s HDD 7200 rpm   35ºC  GPT
Sata #3  /dev/sdc   Seagate  ST1000DM003   931.51 GiB  6.0 Gb/s HDD 7200 rpm   33ºC  GPT
USB3     /dev/sdd   Samsung  S2 Portable   931.51 GiB  480 Mb/s                      GPT

Aproveitei para comprar novos cabos Sata — e não ficou mais nenhum cabo do antigo PC.

Como “mover” uma partição

Copiando uma partição e colando em outra

O GParted e o KDE Partition Manager oferecem o recurso de “mover” uma partição — mas eu sempre preferi “copiar” + “colar”; em seguida testar a “partição-cópia”; e só depois, deletar a “partição-original”. — Isso é bem mais trabalhoso e em 2025 acho desnecessário. Mas foi assim que fiz, durante quase 10 anos, por via das dúvidas.

Quando digo “mover uma partição”, é um modo simplificado de dizer “copiar uma partição e colar em outro lugar” — o que pode ser feito pelo GParted, pelo KDE Partition Manager ou pelo Clonezilla, entre outras ferramentas.

O mais recomendado é fazer isso em uma sessão Live, pois as partições não podem estar montadas. — Como tenho várias distros em dualboot (multiboot), às vezes uso uma para lidar com as partições de alguma outra — dispondo de todas as ferramentas já instaladas e configuradas.

Acima - Exemplo de como “movi” (copiei) uma nova instalação do MX Linux 21 e “colei” na partição onde estava a instalação anterior da mesma distro. — Isso me permite testar a nova instalação (em uma partição provisória), e se der certo, sobrescrever a instalação anterior. — Se a nova instalação não agradar, basta deletá-la, pois a instalação anterior não foi afetada.

Fiz isso ao reinstalar o PCLinuxOS e ao reinstalar o MX Linux 21.

No caso de partições ext4, a cópia terá o mesmo identificador UUID — dispensando a necessidade de editar o arquivo fstab — mas antes de testar a cópia, lembre de desconectar o HDD / SSD onde está o original, caso contrário ambas as partições serão montadas, o que pode gerar problemas.

Se o original e a cópia estiverem no mesmo HDD / SSD, uma saída é alterar o UUID da partição original. — Para voltar a usá-la, edite seu fstab.

Após conferir que a cópia funciona bem, já se pode deletar a partição original.

Capacidades do GParted e do KDE Partition Manager

GParted e KDE Partition Manager não oferecem suporte para copiar partições XFS, por exemplo. — O Live Clonezilla funcionou bem.

xxx

— … ≠ “•” ≠ … —

PC desktop UEFI / GPT

Ferramentas &tc.

Conky - monitor do sistema

Grub enlouquecido com 12 distros em multiboot

Remanejamento de sistemas Linux ao reparticionar discos

Backup total e limpeza das partições de trabalho

Migrando sistemas Linux para disco rígido de 1 Terabyte

Ensaio de avaliação com luckyBackup e Unison

Particionamento de Drive SSD para vários Linux

MX Linux 21 Wildflower KDE - instalação de substituição

noreply@blogger.com (Mboaba) — Sat, 23 Oct 2021 16:21:00 +0000

MX Linux 21 Wildflower •

Eu já tinha instalado o MX Linux Beta1 KDE em Agosto, e funcionou muito bem nesses 2 meses, sem absolutamente nenhum problema. — Por isso, nem me dei o trabalho de testar o Beta2 ou o RC1. — Resolvi substituir, agora, para ter, nos próximos 2 anos, uma instalação “padrão”, da versão aprovada e corrigida.

Primeiro, instalei em uma partição provisória — testei para confirmar que estava tudo certo — e só então “movi” para a partição onde estava o Beta1.

Em suma: - Substituir uma instalação existente — mas só depois de testar e aprovar a nova instalação — do mesmo modo como eu já tinha feito ao substituir a instalação do PCLinuxOS.

Índice

ISO, download, verificação, K3b
Sessão Live
Particionamento manual
Instalação
Teste do MX Linux 21 instalado
Teste do MX Linux 21 com a antiga /home
Substituição do Beta1 instalado antes
Grub, limpeza da /home e teste final
Teste do MX Linux 21 realocado

ISO, download, verificação, K3b

Verificação da imagem ISO pela soma sha256

Baixei a imagem ISO do MX Linux 21 KDE pelo link oficial e verifiquei a integridade do arquivo pela soma sha256.

Verificação da imagem ISO pela soma MD5

Verifiquei a integridade da imagem ISO também pela soma MD5 e “queimei” em DVD, para ter sempre à mão, quando precisar.

Sessão Live

Menu de inicialização do Live MX Linux 21

Ao ligar o computador, o Live MX Linux 21 apresenta seu menu de inicialização já com a 2ª linha pré-selecionada: — “Idioma - Teclado - Fuso horário” — e a experiência com o MX Linux 19 e o MX Linux 21 Beta1 já me convenceu de que é melhor configurar logo essas 3 coisas, antes de iniciar a sessão Live.

Opções avançadas do menu de inicialização do Live MX Linux 21

O mesmo se pode dizer das Opções Avançadas, bem destacadas na 3ª linha do Menu de inicialização do Live MX Linux 21 — em especial para quem deseja explorar seus recursos de Persistência — e neste caso, recomendo ler com atenção a documentação sobre o assunto.

Eu até hoje evitei mexer nas complexidades das opções de Persistência. — Me basta a opção básica, que permite preservar, na instalação em HDD / SSD, as configurações, arquivos etc. da sessão Live — e esse é um dos motivos para definir logo minhas opções de Idioma, Teclado e Fuso horário, antes de iniciar a sessão Live.

Portanto, apenas voltei ao Menu inicial, para cuidar disso.

Opções de Idioma, Teclado, Fuso horário ao iniciar o Live MX Linux 21

Feitas minhas escolhas de Idioma, Teclado e Fuso horário, eu estava pronto para iniciar a sessão Live do MX Linux 21 — já pré-configurada do modo como eu queria, para se transmitir à instalação em HDD / SSD.

Configuração do KDE Spectacle para documentar a sessão Live desde o início

O KDE Spectacle não é minha ferramenta preferida para captura de telas — mas configurei logo no primeiro momento, para documentar todos os detalhes da sessão Live, desde o início.

Instalação do Synaptic pelo apt, para facilitar a configuração da sessão Live

Outro passo importante era instalar logo o Synaptic — pelo apt — para facilitar a configuração da sessão Live, que se transmite à instalação em HDD / SSD.

Habilitar montagem de partições pelo usuário

Eu tinha esquecido de preparar um Pendrive com vários arquivos de que eu ia precisar. — Ok, eu já devia ter colocado tudo isso na nuvem. — O MX Tweak é o caminho mais simples e direto para autorizar o uDisks2 a montar partições “removíveis” (que não fazem parte do sistema), sem pedir senha, pois isto criaria pontos de montagem que não pertencem ao usuário.

Redirecionando tecla de atalho PrtScn para o gnome-screenshot

Instalei o gnome-screenshot e reconfigurei a tecla de atalho PrtScn para usá-lo em lugar do Spectacle. — O que me interessava era capturar e salvar rapidamente, com apenas 1 toque; e em alguns casos capturar com retardo de 7 segundos — tudo automático, sem burocracia.

Baixei, instalei e sincronizei o Google Chrome, para acesso rápido aos meus Bookmarks, redes, fóruns etc. — a minha nuvem.

Antes, instalei o Chromium pelo Synaptic, mas agora já não consegui sincronizar — por isso, removi e instalei o Chrome.

Dos HDDs, eu trouxe os arquivos de configuração do Conky e um papel de parede que o deixa mais legível. — Não é tão elegante quanto o Conky do MX Linux, mas me permitiria monitorar em detalhes o que se passa no sistema durante a instalação.

Particionamento manual

Criando uma partição para instalar o MX Linux 21

Em um espaço não-alocado no final do SSD, criei uma partição provisória “Linux14”, para instalar o MX Linux 21. — Desse modo, eu preservaria a instalação do MX 21 Beta1, que ainda estava na partição “Linux12”.

Partição provisória para o MX Linux 21

Criei essa partição provisória “Linux14” um pouco menor (28 GiB) do que as outras (30 GiB) — desse modo, eu poderia copiá-la, no futuro, para “colar” na partição “Linux12”, quando resolver substituir a instalação anterior, do MX Linux 21 Beta1. — Ao “colar”, ela será expandida para ocupar os 30 GiB disponíveis na partição de destino.

Isso ficará mais claro quando chegar essa hora.

Instalação

Etapas iniciais do Instalador do MX Linux 21

O Instalador do MX Linux 21 já adivinhou que eu preferia Teclado ABNT2 — e pré-seleciona a opção de personalizar a escolha das partições — embora o usuário possa mudar essa opção, caso prefira usar um disco inteiro.

Escolha da partição-raiz para instalar o MX Linux 21

Escolhi apenas a partição-raiz onde eu queria instalar o MX Linux 21.

O instalador propôs outro rótulo (Label); e preferi corrigir para “Linux14”. — Aceitei o formato sugerido (ext4) — e os parâmetros “noatime”, “dump”, Pass “1”, para o /etc/fstab.

Deixei para adicionar, no futuro, uma partição /home separada, partição Swap etc.

Opções de instalação do Grub, UEFi etc. no Instalador do MX Linux 21

Fiquei olhando as opções de Grub, UEFI etc. — sem encontrar nada que eu me sentisse seguro de querer mudar — enquanto o Instalador prosseguuia em sua tarefa (até +/-72%), sem perder tempo.

Hostname, domínio, Samba

Precisei corrigir ou preencher o Hostname “Linux12”, pois o Instalador do MX Linux não poderia adivinhar meus planos para o futuro. — Desabilitei o servidor Samba, que não uso. — Fui obrigado a inventar um domínio qualquer, pois o Instalador não aceitou deixar esse campo vazio.

Localização e serviços no Instalador do MX Linux 21

As configurações de Localização estavam corretas — conforme escolhi no Menu de inicialização da sessão Live do MX Linux 21. — Entre os serviços, apenas desabilitei Cups.

Conta Root, Auto Login do usuário e persistência das modificações na Live

Após configurar a conta de usuário, habilitei a conta root, o Login automático do usuário e a persistência das modificações da sessão Live na instalação em SSD.

Para me certificar do significado desta última opção, abri o Help Desktop (PDF) — que resume tudo o que se precisa saber durante a instalação (e muito mais). — Os atalhos para essa Ajuda e para o FAQ (que ocultei na Área de trabalho) continuam em ~/Desktop, e também no Menu.

Concluí a instalação em 24 minutos, de 0:19 a 0:43, com algumas pausas e demoras para pensar, ler o manual etc.

A sessão Live durou cerca de 3 horas, das 21:45 até 0:43, incluindo as configurações, instalação de pacotes, particionamento e backup final de arquivos para um Pendrive, por precaução.

Para isso, desabilitei a opção de reiniciar automaticamente ao fechar o Instalador. — E, sim, os arquivos da sessão Live foram mantidos na instalação em SSD — mas não custava me precaver.

Teste do MX Linux 21 instalado

Grub do MX Linux 21

O Grub do MX Linux 21 ficou bonito — embora pequeno para 12 distros (é relativamente fácil ampliar esse “retângulo” central) — mas não gerou entradas para o openSUSE Tumbleweed, instalado em partição BtrFS.

Isso é comum, com a maioria das distros que já instalei — mas não é um problema, pois prefiro usar o Grub do próprio openSUSE — e tenho o Grub do Mageia como reserva, para alguma emergência.

Acima - A nova instalação do MX Linux 21, dona do Grub, assume o topo de seu Menu de inicialização. — A instalação anterior (21 Beta1) permanece entre as outras, pela ordem alfa-numérica das partições — sda10, sda11, sda12, sda13, sda3, sda4... (openSUSE em sda2 não aparece).

Reaplicação do papel de parede e disparo do Conky

A persistência não manteve a aplicação do papel de parede — um problema menor — mas ele estava lá, e bastou reaplicar.

O Conky não iniciou automaticamente — o que é normal, pois não configurei isso — mas bastou disparar um comando no Konsole, pois os arquivos de configuração estavam lá.

Também foram preservadas as capturas de tela, as anotações em TXT, o pacote .deb do Chrome — de modo que não precisei do backup no Pendrive.

O Chrome disse que meu perfil estava em uso em outro computador — um caso de excesso de persistência, digamos assim. — Bastou desbloquear, e restaurar a sessão anterior do Chrome.

As demais configurações da sessão Live foram mantidas com sucesso.

Adicionando a antiga /home e a partição Swap à nova instalação do MX Linux 21

Não senti necessidade de continuar testando a nova instalação — nem de perder tempo com muitas outras configurações, que nem cheguei a fazer na sessão Live, pois logo iria obter todas elas, e muitas mais, pela /home da instalação anterior. — Até ali, configurei apenas o suficiente para documentar a instalação e os resultados, com algum conforto.

Bastaram 25 minutos, de 0:56 a 1:21, para me dar por satisfeito com a instalação.

Acima - Copiei para o /etc/fstab as 2 linhas referentes à partição Swap e à partição /home da instalação anterior (MX 21 Beta1) — e reiniciei a máquina.

Teste do MX Linux 21 com a antiga /home

Início do MX Linux 21 KDE com a /home da instalação anterior

A sessão do MX Linux 21 KDE com a /home da instalação anterior já carregou com alto índice de sucesso — a julgar pela minha experiência recente com casos assim.

Um aviso “xmessage” dizia que “Could not start ksmserver” — mas bastou clicar em “Okay” para fechar, e não aparecer mais nas inicializações seguintes.. — Esse aviso aparece, vez por outra, aleatoriamente, em várias distros, inclusive algumas que não têm ksmserver instalado, e depois não se repete mais durante muito tempo.

As partições-raiz das outras distros foram automaticamente montadas — mas não as partições Home1 a Home11. — Isso já me aconteceu várias vezes, ao incorporar uma /home pré-existente, ou ao “mover” essas partições de um HDD para outro, e sei como resolver (em geral com pouco esforço).

As 2 instâncias do Conky iniciaram automaticamente porque na /home da instalação anterior elas já estavam no Autostart. — No Conky2, ficou logo evidente que faltava instalar aha e html2text (para exibir os dados do htop); e o Screenfetch.

No lado esquerdo do Painel, entre os Lançadores (Launchers) do Dolphin e do Kate, faltava remover o ícone (não-exibido) do Chromium e substituir pelo do Chrome.

No lado direito do Painel, junto Relógio, ficou claro que faltava instalar o pacote qml-module-qtquick-xmllistmodel — necessário para exibir o widget Weather (Clima).

“Esquecer” partições “desconectadas”

Minha primeira tentativa para regularizar a montagem automática de partições “removíveis” (as que não fazem parte do sistema) foi entrar em KDE System Settings >> Removable storage >> Removable Devices — desmarcar a opção “Montar automaticamente todas as mídias removíveis no Login”, para ter acesso às opções individuais de cada partição — selecionar todos os itens em “Dispositivos desconectados” e mandar “esquecê-los”.

Esta providência não é suficiente para restabelecer a montagem automática das demais partições “removíveis” — mas em algumas distros é indispensável.

Montagem manual das partições, para “ensinar” o sistema

O passo seguinte foi montar manualmente — pelo Dolphin — todas as partições que não estavam sendo montadas automaticamente pelo uDisks2, no início da sessão KDE Plasma.

Depois disso, a montagem passou a funcionar automaticamente, a cada inicialização.

Acima - Àquela altura, eu já tinha instalado os pacotes necessários, e o Conky2 já exibia os números fornecidos pelo htop — bem como as versões do Qt e do Plasma, fornecidas pelo Screenfetch.

Com isso, considerei testada e aprovada a inclusão da antiga /home na nova instalação do MX Linux 21 KDE.

Recolocando em ordem as opções de boot UEFI

Hora de recolocar o Grub do openSUSE no topo das opções de boot do UEFI.

Substituição do Beta1 instalado antes

“Movendo” a nova instalação do MX Linux 21 para o lugar da anterior

Pelo GParted, “copiei” a partição com a nova instalação do MX Linux 21 e “colei” na partição onde estava a instalação anterior (Beta1), para substituí-la.

aaaa

No detalhe à esquerda: - A partição de 28 GiB é expandida para ocupar todo o espaço da partição de destino (30 GiB).

No detalhe à direita: - Mudei o Rótulo (Label) da partição-cópia para “Linux12” — e alterei o identificador UUID da partição “Linux14” original, para distingui-la de sua cópia.

Grub, limpeza da /home e teste final

zzz

Atualização do Grub, para detectar a nova instalação do MX Linux 21 KDE na partição “Linux12”.

O Conky registrou que a instalação ocupava 7,82 GiB da partição.

Copiando e deletando o conteúdo de /home/UserFolder

O conteúdo da pasta /home/UserFolder já não é necessário — e ficou inacessível pelo MX Linux 21, pois clicar na pasta /home agora leva à partição Home12. — Copiei para uma partição de dados, e em seguida deletei pelo Midnight Commander em modo root.

Com isso, a ocupação da partição-raiz Linux12 diminuiu de 7,82 GiB para 7,49 GiB. — Não se pode dizer que foi uma redução fantástica — mas aquilo não era útil, nem acessível.

aaaa

De volta ao MX Linux 21 KDE, tudo continuava funcionando sem qualquer problema.

Deletei a partição provisória “Linux14”, que já não era necessária.

aaaa

Desabilitei a detecção de outras distros (os_prober) em /etc/default/grub — e a atualização do Grub, que demorava 1 min 20s por comando no Terminal, passou a ser feita em 17 segundos.

Acima - No detalhe à esquerda, “GRUB_DISABLE_OS_PROBER=false”. — À direita, a configuração alterada para “GRUB_DISABLE_OS_PROBER=true”.

Eu tenho 2 motivos para desabilitar os_prober na maioria das distros que uso em dualboot.

Primeiro, porque o Grub de cada distro “lê” o Grub das outras 11 para extrair as informações de cada uma delas — e quanto maiores os arquivos /boot/grub/grub.cfg, mais essa operação demora, usa CPU, aquece etc. — Isso é muito mais notável, quando a instalação ou remoção de Kernel se faz por um aplicativo GUI (Instaladores, gerenciadores de pacotes), que demandam ainda mais recursos e, com frequência, repetem até 3 vezes essa operação.

Segundo, porque o Grub do openSUSE só precisa que o Grub das outras 10 distros indique os parâmetros de cada uma delas — e o Grub de emergência (Mageia), também. — Portanto, “seja breve”.

Não entendo nem 1% das entranhas do Grub. — Me parece um tanto “antigo” — mas ainda é o que oferece mais recursos.

Subtítulo

\\\\

[imagem]

xxx

__________________________
Publicado inicialmente em 23 Outubro 2021

— … ≠ • ≠ … —

PC desktop UEFI / GPT

PCLinuxOS KDE Darkstar - instalação de substituição

noreply@blogger.com (Mboaba) — Fri, 20 Aug 2021 23:48:00 +0000

PCLinuxOS KDE Darkstar, instalado e atualizado

Essa instalação do PCLinuxOS foi um “campo de prova” para:

Substituir uma instalação existente — mas só depois de testar e aprovar a nova instalação

Experimentar a ISO “Darkstar”, com um KDE mais “enxuto” — em contraposição à ISO padrão, que tenho usado desde 2017

Verificar se eu conseguiria concluir a instalação no novo hardware — pois no meu antigo hardware isto exigia manobras especiais — inviáveis no meu hardware atual

Eu já tinha feito muitas alterações na instalação anterior — por exemplo, configurei UXA (numa das tentativas para conseguir usar o GoogleEarth), o que aumentou bastante o uso de Memória RAM, além de eliminar o blur do Plasma — e agora acabei achando mais prático instalar de novo.

Porém, eu não queria apagar a instalação anterior — que estava funcional — antes de concluir e testar a nova instalação.

Por isso, fiz a nova instalação em uma partição provisória “Linux13” — e só depois de testar, “movi” para a partição “Linux6” — sobrescrevendo finalmente a instalação anterior.

Nota: - Isto não é um “tutorial”, mas, apenas, o registro da minha última instalação do PCLinuxOS. — Uma descrição das principais características dessa distro está no 1º link abaixo. — Os 5 links abaixo reúnem minha experiência anterior com o PCLinuxOS:

PCLinuxOS - instalação e configuração (Dezembro 2017)
PCLinuxOS - instalação direta (sem sessão Live) (Dezembro 2017)
PCLinuxOS - Add Locale, LibreOffice manager & Software Center (Janeiro 2018)
PCLinuxOS KDE - instalação e configuração (Agosto 2019)
Transição para hardware UEFI-GPT (Janeiro 2020)

Índice

PCLinuxOS KDE Darkstar
Instalação
Primeiro boot
Atualização inicial
Incorporando a antiga partição /home
Movendo a partição-raiz
Teste na nova partição
Adicionando pacotes
Histórico de pacotes
Uso de Memória RAM (1)
Formatos regionais
Hostname
Uso de Memória RAM (2)
Fontes TTF
Grub & Synaptic
Grub & Draklive-install

PCLinuxOS KDE Darkstar

Torrents para PCLinuxOS em LinuxTracker

9 Agosto 2021 - Baixei a ISO Darkstar mais recente a partir da página de torrents do PCLinuxOS no Linux Tracker. — A imagem ISO tinha 1,62 GB — bem menos que os 2,57 GB da ISO KDE “completa”.

O KTorrent registrou velocidade média de uns 22 GiB/s durante o download, o que está bem perto do limite da minha conexão atual (26 GiB/s). — Verifiquei a integridade do arquivo por md5sum e queimei pelo K3b em DVD, para guardar.

Instalação

xxx

No menu inicial, aceitei a opção-padrão “Start PCLinuxOS Live”.

A única pergunta, a seguir, foi sobre o Teclado, e aceitei o padrão “US keyboard” — pois eu já sabia que não valia a pena tentar mudar isso (e tornei a confirmar, na hora).

Cheguei então à tela de Login (username: guest), com as opções corriqueiras de Idioma (Inglês dos EUA), Sessão, Ações, Configurar, Login remoto via XDMCP, Reiniciar, Desligar.

O relógio exibiu horário UTC, e não me preocupei com isso, pois também já sabia que provavelmente seria perda de tempo. — A ISO “internacional” é Texas, USA — não adianta espernear.

Seleção de um espelho do PCLinuxOS no Brasil

Ao iniciar a sessão Live, estavam instalados 1.612 pacotes, de um total de 16.004 existentes nos repositórios*. — Alterei o espelho para o Brasil e instalei Conky (4 pacotes), lm_sensors (2 pacotes), Neofetch (5 pacotes) — elevando o número para 1.623 pacotes instalados.

(*) Os pacotes do PCLinuxOS são muito mais “agrupados” (menor fragmentação em dependências). — Em 2018, para instalar Dolphin + algumas pré-visualizações de arquivos em uma sessão Live PCLinuxOS Xfce, foram necessários 135 pacotes — enquanto em uma Live do Lite Xfce precisei instalar 272 pacotes; e em uma Live do LMDE Cinnamon, 297 pacotes.

Criando uma partição provisória para instalar o PCLinuxOS

Pelo Conky, verifiquei que as fontes Verdana já estavam presentes na sessão Live.

Partição provisória pronta para instalar o PCLinuxOS

Aproveitei um espaço não-alocado no SSD para criar uma partição de 29,3 GiB (30.000 MiB), com rótulo “Linux13”.

Eu pretendia “mover” essa instalação para a partição onde estava minha instalação anterior do PCLinuxOS (se tudo desse certo), usando o Gparted — e nesses casos, é sempre bom garantir que a partição a ser movida seja igual ou menor do que a partição de destino. — Por precaução, é bom garantir que seja menor.

Após selecionar apenas esta partição “Linux13” e atribuir a ela o ponto de montagem “/”, a instalação do sistema se completou em 4 minutos — mas depois disso, a instalação do Grub2 demorou 10 minutos, em 2 etapas de 5 minutos (ou pouco mais).

Ver “Grub & Draklive-install”, adiante.

Primeiro boot

Grub parcial do PCLinuxOS — limitado ao “retângulo” padrão

9 Agosto 2021 - Embora eu tenha desmarcado a opção de detectar outros sistemas (Probe Foreign OS), o Grub do PCLinuxOS incluiu todos (exceto openSUSE) — em uma lista única (sem submenus), que se prolongava por vários metros, acima e abaixo do retângulo de exibição.

Isso é fácil de corrigir — pelo “Centro de Controle”, ou por comandos. — Só a falta de uma entrada para o openSUSE (que já observei em várias distros), ainda não descobri como resolver. — Mas isso não é problema, pois meu Menu de inicialização é gerenciado pelo próprio openSUSE (em caso de emergência, uso o do Mageia). — O Grub de todas as outras distros não precisa perder tempo com isso.

xxx

Ao inicializar o PCLinuxOS pela primeira vez, fui convidado a escolher o fuso horário (BRT), relógio do sistema (UTC), habilitar sincronização de hora (NTP server: All servers), definir a senha do Administrador (Root), Método de autenticação (aceitei LDAP), criar Usuário (especifiquei UID = 1000).

Na Live do PCLinuxOS, o usuário padrão (UID) e seu grupo (GID) são 500:500 — e na primeira vez que instalei, foi isso que obtive: UID=500, GID=500, o que me atrapalhou, pois todos os meus arquivos pertencem a um usuário-padrão UID=1000. — Foi muito complicado tentar corrigir isso, em 2017 (não consegui; acabei reinstalando o PCLinuxOS), e desde então sempre lembro de especificar 1000:1000 durante o primeiro boot após a instalação.

Na tela de Login (após essas configurações iniciais), eu poderia ter escolhido Inglês britânico (en_UK), mas parece que não fiz isso. Deixei na opção-padrão de usar o “Último Idioma” (o da sessão anterior).

A sessão iniciou com hora UTC+02.

Nesse dia, me limitei a configurar o Spectacle — salvei algumas capturas de tela na “pasta pessoal”, pois ainda não tinha montagem automática das partições de trabalho — e encerrei a sessão após 1 ou 2 minutos.

Ao iniciar o PCLinuxOS outra vez, dias depois, o relógio da tela de Login ainda indicou um horário errado — mas ao iniciar a sessão já indicou a hora BRT (UTC-03).

Espaço usado pelo PCLinuxOS logo após a instalação

Até aquele momento, o PCLinuxOS ocupava 4,7 GiB de espaço em sua partição — incluindo uma pasta /home/USER ainda pouco povoada.

Reorganizando as prioridades de boot pelo efibootmgr

13 Agosto - Dias depois, restabeleci minhas prioridades de boot pelo efibootmgr — openSUSE no topo (e Mageia na reserva) — pois o Grub do PCLinuxOS estava afetando o meu dia-a-dia:

$ efibootmgr
BootCurrent: 0004
Timeout: 1 seconds
BootOrder: 0004,0000,0003,0001,000A,0007,0002,0005,000E,0006,000B
Boot0000* opensuse
Boot0001* debian
Boot0002* Fedora
Boot0003* mageia
Boot0004* pclinuxos
Boot0005* arch_grub
Boot0006* ubuntu
Boot0007* MX19
Boot000A* slackware-14.2+
Boot000B* neon
Boot000E* debian

# efibootmgr -o 0000,0003,0001,000A,0007,0002,0005,000E,0006,000B,0004
BootCurrent: 0004
Timeout: 1 seconds
BootOrder: 0000,0003,0001,000A,0007,0002,0005,000E,0006,000B,0004
Boot0000* opensuse
Boot0001* debian
Boot0002* Fedora
Boot0003* mageia
Boot0004* pclinuxos
Boot0005* arch_grub
Boot0006* ubuntu
Boot0007* MX19
Boot000A* slackware-14.2+
Boot000B* neon
Boot000E* debian

Atualização inicial

As partições adicionais não foram montadas automaticamente

14 Agosto - Pelo comando rpm -qa > file.txt, verifiquei que a instalação trouxe 1.622 pacotes — inclusive Conky, Neofetch, lm_sensors e suas dependências, adicionados durante a sessão Live. — Só o Draklive-install ficou fora.

Constatei que a escolha do espelho (mirror) brasileiro — bem como o histórico do Synaptic (pacotes instalados na sessão Live) — também foram mantidos na instalação.

xxx

10:55 - A atualização inicial instalou mais 2 bibliotecas (avi, dvd).

O botão “Mark all changes” do Synaptic não inclui novas revisões de Kernel, por padrão — nem a instalação de novas versões. — Cabe ao usuário verificar as opções disponíveis e escolher (ou não).

Ao recarregar (Reload) as informações dos repositórios, o Synaptic exibe na seção “New in repository” os pacotes que não constavam de sua listagem anterior. — Se recarregar as informações outra vez, esta sessão se esvazia.

Instalei 2 pacotes de uma nova revisão de Kernel (5.13.10) — e também o pacote “Kernel-Latest”, que automatiza esta opção no Synaptic. — O número de pacotes instalados subiu então para 1.627.

Atualização do Grub, com duas instalações do PCLinuxOS

Com as atualizações + adição de pacotes de Kernel e “Kernel-Latest”, o espaço ocupado em disco aumentou para 5,46 GiB — conforme registrado ao atualizar o Grub do openSUSE.

Em todas as distros que usam Synaptic, mantenho configurado para limpar o cache de pacotes baixados, após serem instalados — o que evita encher demais o disco, e ter de fazer “limpeza” periódica. — Acabei ficando sem alguns bons pacotes, retirados dos repositórios, nos últimos 20 anos, mas isso não foi o fim-do-mundo.

11:50 - Na antiga instalação do PCLinuxOS (Linux6), fiz a atualização geral; e também salvei a lista dos pacotes instalados ($ rpm -qa > file.txt), para comparação.

12:00 - No openSUSE, fiz nova atualização do Grub; e salvei um backup dos arquivos fstab, conky.conf etc. de todas as distros.

Incorporando a antiga partição /home

Inclusão da antiga partição “Home6” no fstab da nova instalação

12:40 - Na antiga instalação do PCLinuxOS (Linux6), copiei o ponto de montagem de sua partição “Home6” para o fstab da nova instalação.

Partições adicionais montadas automaticamente

13:00 - Ao reiniciar a nova instalação do PCLinuxOS — agora com as configurações acumuladas na antiga partição “Home6” — constatei que já fez a montagem automática de todas as partições “adicionais” (removable devices, na terminologia do KDE).

Com isso, eu já podia substituir o KDE Spectacle, que usei a título provisório. — Agora, bastou instalar o gnome-screenshot, — que respondeu de imediato às teclas de atalho PrtScn e Shift+PrtScn, e gravou na partição Warehouse, sem fazer perguntas.

O Conky já iniciou automaticamente com a sessão, pelo Autostart. — Após instalar o Kate, ele já abriu com os 7 arquivos da sessão “anterior”. — Ao instalar o Chromium, ele já abriu configurado e sincronizado — e assim por diante.

Observe que o Synaptic manteve o histórico da sessão Live.

O botão “Get Windows Fonts” depende de existir Windows no PC

13:15 - Tal como eu já tinha notado no Centro de Controle do Mageia (MCC), o recurso “Get Windows Fonts” depende de existir Windows na máquina — mas é fácil instalar manualmente essas fontes a partir de pacotes TTF “avulsos” em algum outro lugar. — Vale como registro, pois na verdade as fontes Verdana, por exemplo, já estavam presentes desde a sessão Live.

Configuração do Login automático no PCLinuxOS

13:18 - Configurar o Login automático pelo “KDE System Settings” não faz nenhum efeito no PCLinuxOS (nem no Mageia, nem no openSUSE). — É necessário configurá-lo pelo “Centro de Controle” dessas distros — indicando o usuário-padrão e a sessão-padrão.

Widgets “Weather” e “Moon phase”

13:30 - O widget “Moon phase” (Gealach) foi automaticamente recuperado da partição “Home6” (configurado para o Hemisfério Sul) — mas o widget Weather precisou ser baixado e configurado de novo.

Movendo a partição-raiz

Substituição da antiga instalação do PCLinuxOS pela nova

13:40 - No openSUSE, desmontei as partições “Linux6” e “Linux13”. — Pelo GParted, “copiei” a partição “Linux13”, com nova instalação do PCLinuxOS, — e “colei” na partição “Linux6”, para finalmente substituir a instalação mais antiga.

A partição “Linux13” tinha 29,3 GiB, e ao ser “colada” na partição “Linux6”, de 30 GiB, foi automaticamente expandida para ocupar o espaço restante.

Configurando a instalação em seu novo local

13:45 - Em seguida, atribuí à cópia o rótulo “Linux6”, para ser identificada e montada como tal, pelo uDisks2 das outras distros — e mudei o UUID da partição “Linux13” — caso contrário, o fstab montaria ambas como partição-raiz do sistema, o que não é recomendável*.

(*) Sim, já me aconteceu uma vez, há uns 5 anos.

Atualização do Grub para o novo local do PCLinuxOS

13:48 - Por fim, atualizei o Grub do openSUSE, para reconhecer a nova localização do PCLinuxOS KDE Darkstar na partição “Linux6” — e o novo UUID da partição “Linux13”, que ainda ficou de reserva, para o caso de algo não dar certo.

Teste na nova partição

Desativando Os-Prober no PCLinuxOS

14:10 - A instalação do PCLinuxOS KDE Darkstar carregou sem qualquer problema, a partir de sua nova localização na partição “Linux6”, e funcionou com perfeição — como se nunca tivesse estado em outro lugar.

Uma vez que o Menu de inicialização da máquina é gerenciado pelo Grub do openSUSE, não há motivo para o Grub do PCLinuxOS perder tempo detectando outras distros — o que torna demorada a instalação de novas revisões de Kernel. — Portanto, desabilitei isso no arquivo /etc/default/grub:

GRUB_DISABLE_OS_PROBER=true

e atualizei o Grub2 do PCLinuxOS para conferir o resultado:

# history
    1                      sensors detect
    2                      sensors-detect
    3  2021-08-14_14-03-12 date; time grub2-mkconfig -o /boot/grub2/grub.cfg; date
    4  2021-08-14_14-04-37 mc
    5  2021-08-14_14-09-56 date; time grub2-mkconfig -o /boot/grub2/grub.cfg; date
...
    9  2021-08-14_14-58-32 npm install -g corona-cli@latest

Deletando a partição provisória

14:15 - Após mais algumas verificações, desmontei a partição “Linux13” e deletei pelo GParted.

Adicionando pacotes

Diferença de 570 pacotes entre a antiga e a nova instalação

14:20 ~ 18:00 - Ainda no dia 14, comparei a lista de pacotes dessa instalação PCLinuxOS KDE Darkstar com a lista de pacotes da instalação antiga:

  386  2021-08-14_12-29-01 diff pc1_post.txt pc2_post.txt | grep '>' > Diff-rpm-qa-to2.txt
  387  2021-08-14_12-30-28 diff pc1_post.txt pc2_post.txt | grep '<' > Diff-rpm-qa-to1.txt

e fui adicionando os que me pareceram mais necessários no momento. — Com isso, o total subiu para 1.773 pacotes instalados; e o espaço ocupado em disco subiu para 7,71 GiB (com uma atualização do Chromium no dia 15).

Nenhum Akonadi tinha sido instalado — um dos sinais de KDE “enxuto”. — Na instalação antiga, com um KDE um pouco maior, o Akonadi estava presente, embora não em atividade.

Instalação do “corona-cli”

14:56 - Instalei o aplicativo corona-cli pelo comando:

# npm install -g corona-cli@latest

Não entendo nada de npm. — Só sei que, no PCLinuxOS, basta o node (1 pacote).

Para uma noção mais realista sobre o “número de pacotes disponíveis” nos repositórios de uma ou de outra distro: — No Mageia, bastou instalar npm (4 pacotes). — No Fedora, npm (5 pacotes). — No openSUSE, npm10 (4 pacotes). — No Arch, npm (6 pacotes). — No Void, nodejs (3 pacotes). — No Debian testing, a instalação do nodejs envolveu 285 pacotes, em Março 2020. — Agora, no MX Linux 21 Beta1 (bullseye), a instalação do pacote npm envolveu 170 pacotes — além do nodejs, (3 pacotes), que instalei antes e não foi suficiente (mas é necessário, pois agora sua remoção exigiria instalar outros pacotes, em substituição). — Como disse, não entendo nada do assunto. Não sei se poderia resolver com menos pacotes, mas tenho a impressão de que não

Gerenciador de LibreOffice no PCLinuxOS

17:45 - Para instalar o LibreOffice, primeiro atualizei o sistema pelo Synaptic — e depois abri o gerenciador do LibreOffice no submenu “Software Center.

O primeiro passo é escolher o Idioma a ser usado no LibreOffice — e se quiser adicionar outros Idiomas, repita o processo mais tarde. — Este também é o caminho para atualizá-lo (dentro do LibreOffice, você pode verificar se há nova versão, em Help >> Check for updates).

No Synaptic, o LibreOffice sempre aparece em “Obsolete”. — Apenas ignore, sempre!

Eu deveria escolher o Idioma Inglês Britânico, já que esta é minha opção para o sistema — mas não encontro nenhuma captura de tela mostrando que eu tenha feito essa escolha.

A mensagem seguinte pergunta se deseja apagar o cache de pacotes baixados, depois de concluir sua instalação.

Segue-se um mostrador de progresso do download, e depois um aviso para esperar até que apareça a mensagem final: — “O novo local do LibreOffice está disponível no submenu Office”.

O processo pode parecer “primitivo”, para novos usuários acostumados ao mundo das lojinhas de consumismo — mas baixou apenas 200 MiB, e ocupou apenas 0,06 GiB em disco. — Em comparação, no meu Debian o LibreOffice tem toneladas de Idiomas (com as respectivas Ajudas), ocupa grande espaço em disco, e exige downloads enormes a cada atualização.

Histórico de pacotes

Histórico resumido dos pacotes, pelo comando $ rpm -qa --last > file.txt:

--------------------------------------------------------------------------
kcalc-21.08.0-1pclos2021                      Sat 21 Aug 2021 18:40:20 -03
--------------------------------------------------------------------------
vlc-3.0.16-4pclos2021                       * Sat 21 Aug 2021 11:52:14 -03
lua5.2-5.2.4-5pclos2021                       Sat 21 Aug 2021 11:52:13 -03
lib64matroska6-1.5.2-1pclos2019               Sat 21 Aug 2021 11:52:13 -03
lib64ebml4-1.3.10-1pclos2020                  Sat 21 Aug 2021 11:52:13 -03
-----------------------------------------------------------------------------
filelight-21.08.0-1pclos2021                  Sat 14 Aug 2021 05:57:51 PM -03
------------------------------- LibreOffice ---------------------------------
libreoffice7.1-freedesktop-menus-7.1.5-2      Sat 14 Aug 2021 05:46:24 PM -03
libobasis7.1-xsltfilter-7.1.5.2-2             Sat 14 Aug 2021 05:46:24 PM -03
libobasis7.1-python-script-provider-7.1.5.2-2 Sat 14 Aug 2021 05:46:24 PM -03
libobasis7.1-ooolinguistic-7.1.5.2-2          Sat 14 Aug 2021 05:46:23 PM -03
libobasis7.1-onlineupdate-7.1.5.2-2           Sat 14 Aug 2021 05:46:23 PM -03
libobasis7.1-libreofficekit-data-7.1.5.2-2    Sat 14 Aug 2021 05:46:23 PM -03
libobasis7.1-graphicfilter-7.1.5.2-2          Sat 14 Aug 2021 05:46:23 PM -03
libobasis7.1-gnome-integration-7.1.5.2-2      Sat 14 Aug 2021 05:46:23 PM -03
libobasis7.1-firebird-7.1.5.2-2               Sat 14 Aug 2021 05:46:23 PM -03
libobasis7.1-extension-report-builder-7.1.5.2-2 Sat 14 Aug 2021 05:46:23 PM -03
libobasis7.1-postgresql-sdbc-7.1.5.2-2        Sat 14 Aug 2021 05:46:22 PM -03
libobasis7.1-extension-pdf-import-7.1.5.2-2   Sat 14 Aug 2021 05:46:22 PM -03
libobasis7.1-extension-nlpsolver-7.1.5.2-2    Sat 14 Aug 2021 05:46:22 PM -03
libobasis7.1-extension-mediawiki-publisher-7.1.5.2-2 Sat 14 Aug 2021 05:46:22 PM -03
libobasis7.1-extension-javascript-script-provider-7.1.5.2-2 Sat 14 Aug 2021 05:46:22 PM -03
libobasis7.1-extension-beanshell-script-provider-7.1.5.2-2 Sat 14 Aug 2021 05:46:22 PM -03
libreoffice7.1-writer-7.1.5.2-2               Sat 14 Aug 2021 05:46:21 PM -03
libreoffice7.1-impress-7.1.5.2-2              Sat 14 Aug 2021 05:46:21 PM -03
libreoffice7.1-en-US-7.1.5.2-2                Sat 14 Aug 2021 05:46:21 PM -03
libreoffice7.1-draw-7.1.5.2-2                 Sat 14 Aug 2021 05:46:21 PM -03
libreoffice7.1-dict-fr-7.1.5.2-2              Sat 14 Aug 2021 05:46:21 PM -03
libobasis7.1-ogltrans-7.1.5.2-2               Sat 14 Aug 2021 05:46:21 PM -03
libobasis7.1-en-US-help-7.1.5.2-2             Sat 14 Aug 2021 05:46:21 PM -03
libreoffice7.1-math-7.1.5.2-2                 Sat 14 Aug 2021 05:46:20 PM -03
libreoffice7.1-dict-es-7.1.5.2-2              Sat 14 Aug 2021 05:46:20 PM -03
libreoffice7.1-dict-en-7.1.5.2-2              Sat 14 Aug 2021 05:46:20 PM -03
libreoffice7.1-calc-7.1.5.2-2                 Sat 14 Aug 2021 05:46:20 PM -03
libreoffice7.1-base-7.1.5.2-2                 Sat 14 Aug 2021 05:46:20 PM -03
libobasis7.1-librelogo-7.1.5.2-2              Sat 14 Aug 2021 05:46:20 PM -03
libreoffice7.1-7.1.5.2-2                      Sat 14 Aug 2021 05:46:19 PM -03
libobasis7.1-pyuno-7.1.5.2-2                  Sat 14 Aug 2021 05:46:19 PM -03
libobasis7.1-math-7.1.5.2-2                   Sat 14 Aug 2021 05:46:19 PM -03
libobasis7.1-images-7.1.5.2-2                 Sat 14 Aug 2021 05:46:19 PM -03
libobasis7.1-writer-7.1.5.2-2                 Sat 14 Aug 2021 05:46:18 PM -03
libobasis7.1-impress-7.1.5.2-2                Sat 14 Aug 2021 05:46:18 PM -03
libobasis7.1-en-US-7.1.5.2-2                  Sat 14 Aug 2021 05:46:18 PM -03
libobasis7.1-draw-7.1.5.2-2                   Sat 14 Aug 2021 05:46:18 PM -03
libobasis7.1-calc-7.1.5.2-2                   Sat 14 Aug 2021 05:46:18 PM -03
libobasis7.1-base-7.1.5.2-2                   Sat 14 Aug 2021 05:46:18 PM -03
libobasis7.1-core-7.1.5.2-2                   Sat 14 Aug 2021 05:46:17 PM -03
libreoffice7.1-ure-7.1.5.2-2                  Sat 14 Aug 2021 05:46:15 PM -03
libobasis7.1-ooofonts-7.1.5.2-2               Sat 14 Aug 2021 05:46:15 PM -03
task-java-2019-1pclos2019                     Sat 14 Aug 2021 05:45:58 PM -03
java-sun-16-2pclos2021                        Sat 14 Aug 2021 05:45:58 PM -03
-----------------------------------------------------------------------------
kdesdk-thumbnailers-21.08.0-1pclos2021        Sat 14 Aug 2021 03:46:44 PM -03
-----------------------------------------------------------------------------
kde-thumbnailer-epub-1.1-1pclos2017           Sat 14 Aug 2021 03:45:07 PM -03
-----------------------------------------------------------------------------
marble-21.08.0-1pclos2021                     Sat 14 Aug 2021 03:40:06 PM -03
lib64wlocate0-1.1-0.2pclos2019                Sat 14 Aug 2021 03:40:05 PM -03
lib64shapelib2-1.5.0-3pclos2021               Sat 14 Aug 2021 03:40:05 PM -03
-----------------------------------------------------------------------------
sshfs-fuse-2.4-2pclos2020                     Sat 14 Aug 2021 03:13:41 PM -03
lib64kf5pulseaudioqt_3-1.3-1pclos2021         Sat 14 Aug 2021 03:13:41 PM -03
lib64fakekey0-0.1-3pclos2019                  Sat 14 Aug 2021 03:13:41 PM -03
kdeconnect-kde-21.08.0-1pclos2021             Sat 14 Aug 2021 03:13:41 PM -03
-----------------------------------------------------------------------------
html2text-1.3.2a-5pclos2011                   Sat 14 Aug 2021 03:10:49 PM -03
-----------------------------------------------------------------------------
htop-3.0.5-1pclos2021                         Sat 14 Aug 2021 03:10:10 PM -03
-----------------------------------------------------------------------------
kim5-1.0-1pclos2019                           Sat 14 Aug 2021 03:03:45 PM -03
-----------------------------------------------------------------------------
node-12.18.3-1pclos2020                       Sat 14 Aug 2021 02:56:38 PM -03
-----------------------------------------------------------------------------
filezilla-3.55.1-1pclos2021                   Sat 14 Aug 2021 02:54:10 PM -03
libstorj-1.0.3-4pclos2021                     Sat 14 Aug 2021 02:54:09 PM -03
libfilezilla-i18n-0.31.1-1pclos2021           Sat 14 Aug 2021 02:54:09 PM -03
lib64uv1-1.41.1-1pclos2021                    Sat 14 Aug 2021 02:54:09 PM -03
lib64storj0-1.0.3-4pclos2021                  Sat 14 Aug 2021 02:54:09 PM -03
lib64filezilla16-0.31.1-1pclos2021            Sat 14 Aug 2021 02:54:09 PM -03
-----------------------------------------------------------------------------
hddtemp-0.3-1pclos2021                        Sat 14 Aug 2021 02:51:51 PM -03
-----------------------------------------------------------------------------
stellarium-0.21.1-1pclos2021                  Sat 14 Aug 2021 02:51:04 PM -03
lib64qt5serialport5-5.15.2-2pclos2020         Sat 14 Aug 2021 02:50:56 PM -03
-----------------------------------------------------------------------------
kstars-3.4.3-1pclos2020                       Sat 14 Aug 2021 02:50:28 PM -03
qtdatavis3d5-5.15.2-2pclos2020                Sat 14 Aug 2021 02:50:25 PM -03
qt5keychain-0.11.1-2pclos2020                 Sat 14 Aug 2021 02:50:25 PM -03
lib64wcs6-6.2-1pclos2019                      Sat 14 Aug 2021 02:50:25 PM -03
lib64qt5websockets5-5.15.2-3pclos2021         Sat 14 Aug 2021 02:50:25 PM -03
lib64qt5keychain1-0.11.1-2pclos2020           Sat 14 Aug 2021 02:50:25 PM -03
lib64qt5datavisualization5-5.15.2-2pclos2020  Sat 14 Aug 2021 02:50:25 PM -03
indilib-1.7.8-2pclos2019                      Sat 14 Aug 2021 02:50:25 PM -03
lib64nova0-0.13.0-3pclos2019                  Sat 14 Aug 2021 02:50:24 PM -03
lib64indi1-1.7.8-2pclos2019                   Sat 14 Aug 2021 02:50:24 PM -03
lib64gslcblas0-2.6-1pclos2019                 Sat 14 Aug 2021 02:50:24 PM -03
lib64gsl25-2.6-1pclos2019                     Sat 14 Aug 2021 02:50:24 PM -03
-----------------------------------------------------------------------------
Removed:   aisleriot                          Sat Aug 14 14:46:09 2021
-----------------------------------------------------------------------------
kdiff3-1.9.2-1pclos2021                       Sat 14 Aug 2021 02:43:21 PM -03
-----------------------------------------------------------------------------
lib64magick-7Q16HDRI_9-7.0.10.62-3pclos2021   Sat 14 Aug 2021 02:42:15 PM -03
lib64lqr0-0.4.2-2pclos2019                    Sat 14 Aug 2021 02:42:15 PM -03
imagemagick-7.0.10.62-3pclos2021              Sat 14 Aug 2021 02:42:15 PM -03
-----------------------------------------------------------------------------
lib64podofo0.9.6-0.9.6-1pclos2021             Sat 14 Aug 2021 02:41:28 PM -03
krename-5.0.1-1pclos2021                      Sat 14 Aug 2021 02:41:28 PM -03
-----------------------------------------------------------------------------
python-eyed3-0.7.3-1pclos2013                 Sat 14 Aug 2021 02:41:09 PM -03
python-exif-1.0.8-3pclos2013                  Sat 14 Aug 2021 02:41:09 PM -03
pyrenamer-0.6.0-3pclos2013                  * Sat 14 Aug 2021 02:41:09 PM -03
gnome-python-gconf-2.28.1-4pclos2013          Sat 14 Aug 2021 02:41:09 PM -03
-----------------------------------------------------------------------------
k3b-21.08.0-1pclos2021                      * Sat 14 Aug 2021 02:34:12 PM -03
vcdimager-2.0.1-1pclos2021                    Sat 14 Aug 2021 02:34:11 PM -03
normalize-0.7.7-3pclos2013                    Sat 14 Aug 2021 02:34:11 PM -03
libkcddb5-21.08.0-1pclos2021                  Sat 14 Aug 2021 02:34:11 PM -03
lib64vcd0-2.0.1-1pclos2021                    Sat 14 Aug 2021 02:34:11 PM -03
lib64musicbrainz5_1-5.1.0-3pclos2019          Sat 14 Aug 2021 02:34:11 PM -03
lib64musicbrainz4-2.1.5-4pclos2019            Sat 14 Aug 2021 02:34:11 PM -03
lib64kcddb5-21.08.0-1pclos2021                Sat 14 Aug 2021 02:34:11 PM -03
lib64iso9660_11-2.1.0-1pclos2021              Sat 14 Aug 2021 02:34:11 PM -03
lib64flac++6-1.3.3-2pclos2021                 Sat 14 Aug 2021 02:34:11 PM -03
lib64burn4-1.5.4-1pclos2021                   Sat 14 Aug 2021 02:34:11 PM -03
dvd+rw-tools-7.1-2pclos2011                   Sat 14 Aug 2021 02:34:11 PM -03
cdrskin-1.5.4-1pclos2021                      Sat 14 Aug 2021 02:34:11 PM -03
cdrdao-1.2.4-1pclos2021                       Sat 14 Aug 2021 02:34:11 PM -03
-----------------------------------------------------------------------------
libktorrent-21.08.0-1pclos2021                Sat 14 Aug 2021 02:33:31 PM -03
lib64kf5plotting5-5.85.0-1pclos2021           Sat 14 Aug 2021 02:33:31 PM -03
lib64kf5ktorrent6-21.08.0-1pclos2021          Sat 14 Aug 2021 02:33:31 PM -03
ktorrent-21.08.0-1pclos2021                 * Sat 14 Aug 2021 02:33:31 PM -03
geoip-1.6.12-1pclos2019                       Sat 14 Aug 2021 02:33:31 PM -03
lib64geoip1-1.6.12-1pclos2019                 Sat 14 Aug 2021 02:33:29 PM -03
-----------------------------------------------------------------------------
kruler-21.08.0-1pclos2021                     Sat 14 Aug 2021 02:31:59 PM -03
-----------------------------------------------------------------------------
gimp-2.10.24-2pclos2021                     * Sat 14 Aug 2021 02:30:47 PM -03
mypaint-brushes-2.0.2-2pclos2021              Sat 14 Aug 2021 02:30:45 PM -03
lib64spiro1-20190731-1pclos2019               Sat 14 Aug 2021 02:30:45 PM -03
lib64devil1-1.7.8-6pclos2021                  Sat 14 Aug 2021 02:30:45 PM -03
lib64allegro4.4-4.4.3.1-1pclos2019            Sat 14 Aug 2021 02:30:45 PM -03
graphviz-2.38.0-2pclos2017                    Sat 14 Aug 2021 02:30:45 PM -03
gegl-0.4.30-2pclos2021                        Sat 14 Aug 2021 02:30:45 PM -03
libheif-1.12.0-1pclos2021                     Sat 14 Aug 2021 02:30:44 PM -03
libde265-1.0.8-1pclos2020                     Sat 14 Aug 2021 02:30:44 PM -03
lib64wmf0.2_7-0.2.8.4-18pclos2019             Sat 14 Aug 2021 02:30:44 PM -03
lib64umfpack5-4.4.6-1pclos2019                Sat 14 Aug 2021 02:30:44 PM -03
lib64mypaint0-1.6.1-1pclos2021                Sat 14 Aug 2021 02:30:44 PM -03
lib64heif1-1.12.0-1pclos2021                  Sat 14 Aug 2021 02:30:44 PM -03
lib64gimp2.0_0-2.10.24-2pclos2021             Sat 14 Aug 2021 02:30:44 PM -03
lib64gegl0.4_0-0.4.30-2pclos2021              Sat 14 Aug 2021 02:30:44 PM -03
lib64colamd2-4.4.6-1pclos2019                 Sat 14 Aug 2021 02:30:44 PM -03
lib64cholmod3-4.4.6-1pclos2019                Sat 14 Aug 2021 02:30:44 PM -03
gimp-python-2.10.24-2pclos2021                Sat 14 Aug 2021 02:30:44 PM -03
lib64suitesparseconfig4-4.4.6-1pclos2019      Sat 14 Aug 2021 02:30:43 PM -03
lib64poppler-glib8-0.90.1-2pclos2021          Sat 14 Aug 2021 02:30:43 PM -03
lib64pathplan4-2.38.0-2pclos2017              Sat 14 Aug 2021 02:30:43 PM -03
lib64gvpr2-2.38.0-2pclos2017                  Sat 14 Aug 2021 02:30:43 PM -03
lib64gvc6-2.38.0-2pclos2017                   Sat 14 Aug 2021 02:30:43 PM -03
lib64gexiv2_2-0.12.2-1pclos2021               Sat 14 Aug 2021 02:30:43 PM -03
lib64cgraph6-2.38.0-2pclos2017                Sat 14 Aug 2021 02:30:43 PM -03
lib64cdt5-2.38.0-2pclos2017                   Sat 14 Aug 2021 02:30:43 PM -03
lib64ccolamd2-4.4.6-1pclos2019                Sat 14 Aug 2021 02:30:43 PM -03
lib64camd2-4.4.6-1pclos2019                   Sat 14 Aug 2021 02:30:43 PM -03
lib64babl0.1_0-0.1.86-1pclos2021              Sat 14 Aug 2021 02:30:43 PM -03
lib64amd2-4.4.6-1pclos2019                    Sat 14 Aug 2021 02:30:43 PM -03
-----------------------------------------------------------------------------
speedtest-0.4.1-2pclos2021                    Sat 14 Aug 2021 02:27:19 PM -03
-----------------------------------------------------------------------------
youtube-dlx-2021.06.06-1pclos2021             Sat 14 Aug 2021 02:26:09 PM -03
-----------------------------------------------------------------------------
xsane-0.999-2pclos2019                        Sat 14 Aug 2021 02:21:13 PM -03
-----------------------------------------------------------------------------
screenfetch-3.9.1-1pclos2019                  Sat 14 Aug 2021 02:20:14 PM -03
-----------------------------------------------------------------------------
chromium-browser (92.0.4515.107-1pclos2021)   Sat Aug 14      13:12:14 2021
-----------------------------------------------------------------------------
kate-21.08.0-1pclos2021                       Sat 14 Aug 2021 01:05:45 PM -03
-----------------------------------------------------------------------------
gnome-screenshot-3.10.0-1pclos2013            Sat 14 Aug 2021 01:02:46 PM -03
-----------------------------------------------------------------------------
kernel-latest-5.13.10.pclos1-1pclos2021       Sat 14 Aug 2021 11:14:13 AM -03
-----------------------------------------------------------------------------
kernel-devel-5.13.10-pclos1-1-1pclos2021      Sat 14 Aug 2021 11:10:49 AM -03
kernel-5.13.10-pclos1-1-1pclos2021            Sat 14 Aug 2021 11:05:30 AM -03
---------------------------------- updates ----------------------------------
ldetect-lst-0.6.31-10pclos2021                Sat 14 Aug 2021 10:58:26 AM -03
binutils-2.37-6pclos2021                      Sat 14 Aug 2021 10:58:26 AM -03
breeze-icons-5.85.0-1pclos2021                Sat 14 Aug 2021 10:58:25 AM -03
firefox-91.0-1pclos2021                       Sat 14 Aug 2021 10:58:23 AM -03
x11-driver-input-wacom-0.40.0-1pclos2021      Sat 14 Aug 2021 10:58:18 AM -03
terminus-font-4.49.1-1pclos2021               Sat 14 Aug 2021 10:58:18 AM -03
sdparm-1.12-1pclos2021                        Sat 14 Aug 2021 10:58:18 AM -03
phonon4qt5-vlc-0.11.3-1pclos2021              Sat 14 Aug 2021 10:58:18 AM -03
mtools-4.0.34-1pclos2021                      Sat 14 Aug 2021 10:58:18 AM -03
kapidox-5.85.0-1pclos2021                     Sat 14 Aug 2021 10:58:18 AM -03
inxi-3.3.06-1pclos2021                        Sat 14 Aug 2021 10:58:18 AM -03
lib64xres1-1.2.1-1pclos2021                   Sat 14 Aug 2021 10:58:17 AM -03
lib64xfont2_2-2.0.5-1pclos2021                Sat 14 Aug 2021 10:58:17 AM -03
lib64xaw7-1.0.14-1pclos2021                   Sat 14 Aug 2021 10:58:17 AM -03
lib64relp0-1.10.0-1pclos2021                  Sat 14 Aug 2021 10:58:17 AM -03
lib64ogg0-1.3.5-2pclos2021                    Sat 14 Aug 2021 10:58:17 AM -03
lib64ksba8-1.6.0-2pclos2021                   Sat 14 Aug 2021 10:58:17 AM -03
lib64kf5prison5-5.85.0-1pclos2021             Sat 14 Aug 2021 10:58:17 AM -03
lib64kf5networkmanagerqt5-5.85.0-1pclos2021   Sat 14 Aug 2021 10:58:17 AM -03
lib64kf5modemmanagerqt5-5.85.0-1pclos2021     Sat 14 Aug 2021 10:58:17 AM -03
lib64jasper4-2.0.32-1pclos2021                Sat 14 Aug 2021 10:58:17 AM -03
kquickcharts-5.85.0-1pclos2021                Sat 14 Aug 2021 10:58:17 AM -03
irqbalance-1.8.0-1pclos2021                   Sat 14 Aug 2021 10:58:17 AM -03
cpupower-5.13.10.pclos1-1pclos2021            Sat 14 Aug 2021 10:58:17 AM -03
bluez-qt-5.85.0-1pclos2021                    Sat 14 Aug 2021 10:58:17 AM -03
sonnet-5.85.0-1pclos2021                      Sat 14 Aug 2021 10:58:16 AM -03
lib64kf5unitconversion5-5.85.0-1pclos2021     Sat 14 Aug 2021 10:58:16 AM -03
kpeople-5.85.0-1pclos2021                     Sat 14 Aug 2021 10:58:16 AM -03
kemoticons-5.85.0-1pclos2021                  Sat 14 Aug 2021 10:58:16 AM -03
diffutils-3.8-1pclos2021                      Sat 14 Aug 2021 10:58:16 AM -03
at-3.2.2-1pclos2021                           Sat 14 Aug 2021 10:58:16 AM -03
sweeper-21.08.0-1pclos2021                    Sat 14 Aug 2021 10:58:15 AM -03
mesa-iris-21.2.0-3pclos2021                   Sat 14 Aug 2021 10:58:15 AM -03
lib64va2-2.12.0-1pclos2021                    Sat 14 Aug 2021 10:58:15 AM -03
kdesu-5.85.0-1pclos2021                       Sat 14 Aug 2021 10:58:15 AM -03
mesa-opencl-21.2.0-3pclos2021                 Sat 14 Aug 2021 10:58:14 AM -03
kwrite-21.08.0-1pclos2021                     Sat 14 Aug 2021 10:58:14 AM -03
kwalletmanager-21.08.0-1pclos2021             Sat 14 Aug 2021 10:58:14 AM -03
kross-5.85.0-1pclos2021                       Sat 14 Aug 2021 10:58:14 AM -03
kfind-21.08.0-1pclos2021                      Sat 14 Aug 2021 10:58:14 AM -03
kdialog-21.08.0-1pclos2021                    Sat 14 Aug 2021 10:58:14 AM -03
ffmpegthumbs-21.08.0-1pclos2021               Sat 14 Aug 2021 10:58:14 AM -03
ark-21.08.0-1pclos2021                        Sat 14 Aug 2021 10:58:14 AM -03
aom-3.1.2-1pclos2021                          Sat 14 Aug 2021 10:58:14 AM -03
spectacle-21.08.0-1pclos2021                  Sat 14 Aug 2021 10:58:13 AM -03
qttools5-5.15.2-3pclos2021                    Sat 14 Aug 2021 10:58:13 AM -03
ktexteditor-plugins-21.08.0-1pclos2021        Sat 14 Aug 2021 10:58:13 AM -03
krunner-5.85.0-1pclos2021                     Sat 14 Aug 2021 10:58:13 AM -03
konsole-21.08.0-1pclos2021                    Sat 14 Aug 2021 10:58:13 AM -03
kdegraphics-thumbnailers-21.08.0-1pclos2021   Sat 14 Aug 2021 10:58:13 AM -03
dav1d-0.9.1-1pclos2021                        Sat 14 Aug 2021 10:58:13 AM -03
okular-21.08.0-1pclos2021                     Sat 14 Aug 2021 10:58:12 AM -03
kjsembed-5.85.0-1pclos2021                    Sat 14 Aug 2021 10:58:12 AM -03
initscripts-9.26-19pclos2021                  Sat 14 Aug 2021 10:58:12 AM -03
gwenview-21.08.0-1pclos2021                   Sat 14 Aug 2021 10:58:12 AM -03
frameworkintegration-5.85.0-1pclos2021        Sat 14 Aug 2021 10:58:12 AM -03
dolphin-plugins-21.08.0-1pclos2021            Sat 14 Aug 2021 10:58:12 AM -03
qqc2-desktop-style-5.85.0-1pclos2021          Sat 14 Aug 2021 10:58:11 AM -03
lib64input10-1.18.1-1pclos2021                Sat 14 Aug 2021 10:58:11 AM -03
lib64dvdnav4-6.1.1-1pclos2021                 Sat 14 Aug 2021 10:58:11 AM -03
khelpcenter-21.08.0-1pclos2021                Sat 14 Aug 2021 10:58:11 AM -03
qttools5-qtdbus-5.15.2-3pclos2021             Sat 14 Aug 2021 10:58:10 AM -03
qca2-qt5-2.3.3-1pclos2021                     Sat 14 Aug 2021 10:58:10 AM -03
networkmanager-1.32.8-2pclos2021              Sat 14 Aug 2021 10:58:10 AM -03
glibc-devel-2.33-9pclos2021                   Sat 14 Aug 2021 10:58:10 AM -03
qttools5-qtpaths-5.15.2-3pclos2021            Sat 14 Aug 2021 10:58:09 AM -03
pango-1.48.8-1pclos2021                       Sat 14 Aug 2021 10:58:09 AM -03
libxkbcommon-1.3.0-1pclos2021                 Sat 14 Aug 2021 10:58:09 AM -03
libinput-udev-1.18.1-1pclos2021               Sat 14 Aug 2021 10:58:09 AM -03
lib64xkbcommon0-1.3.0-1pclos2021              Sat 14 Aug 2021 10:58:09 AM -03
lib64xft2-2.3.4-1pclos2021                    Sat 14 Aug 2021 10:58:09 AM -03
lib64qca2-qt5_2-2.3.3-1pclos2021              Sat 14 Aug 2021 10:58:09 AM -03
lib64pango1.0_0-1.48.8-1pclos2021             Sat 14 Aug 2021 10:58:09 AM -03
lib64ndp0-1.8-1pclos2021                      Sat 14 Aug 2021 10:58:09 AM -03
lib64imlib2_1-loaders-1.7.2-1pclos2021        Sat 14 Aug 2021 10:58:09 AM -03
lib64imlib2_1-filters-1.7.2-1pclos2021        Sat 14 Aug 2021 10:58:09 AM -03
lib64imlib2_1-1.7.2-1pclos2021                Sat 14 Aug 2021 10:58:09 AM -03
kernel-userspace-headers-5.13.10-1pclos2021   Sat 14 Aug 2021 10:58:09 AM -03
lib64pcre1-8.45-1pclos2021                    Sat 14 Aug 2021 10:58:08 AM -03
lib64kitemmodels5-5.85.0-1pclos2021           Sat 14 Aug 2021 10:58:08 AM -03
lib64kf5holidays5-21.08.0-1pclos2021          Sat 14 Aug 2021 10:58:08 AM -03
lib64dvdread8-6.1.2-1pclos2021                Sat 14 Aug 2021 10:58:08 AM -03
kjs-5.85.0-1pclos2021                         Sat 14 Aug 2021 10:58:08 AM -03
kirigami-5.85.0-1pclos2021                    Sat 14 Aug 2021 10:58:08 AM -03
kinit-5.85.0-1pclos2021                       Sat 14 Aug 2021 10:58:08 AM -03
khtml-5.85.0-1pclos2021                       Sat 14 Aug 2021 10:58:08 AM -03
kholidays-21.08.0-1pclos2021                  Sat 14 Aug 2021 10:58:08 AM -03
dolphin-21.08.0-1pclos2021                    Sat 14 Aug 2021 10:58:08 AM -03
lib64xcrypt-devel-4.4.25-1pclos2021           Sat 14 Aug 2021 10:58:07 AM -03
lib64kf5syndication5-21.08.0-1pclos2021       Sat 14 Aug 2021 10:58:07 AM -03
lib64kf5kdnssd5-5.85.0-1pclos2021             Sat 14 Aug 2021 10:58:07 AM -03
lib64ext2fs2-1.46.3-2pclos2021                Sat 14 Aug 2021 10:58:07 AM -03
lib64cap2-2.52-1pclos2021                     Sat 14 Aug 2021 10:58:07 AM -03
knewstuff-5.85.0-1pclos2021                   Sat 14 Aug 2021 10:58:07 AM -03
kio-extras-21.08.0-1pclos2021                 Sat 14 Aug 2021 10:58:07 AM -03
kidletime-5.85.0-1pclos2021                   Sat 14 Aug 2021 10:58:07 AM -03
kded-5.85.0-1pclos2021                        Sat 14 Aug 2021 10:58:07 AM -03
e2fsprogs-1.46.3-2pclos2021                   Sat 14 Aug 2021 10:58:07 AM -03
baloo-widgets-21.08.0-1pclos2021              Sat 14 Aug 2021 10:58:07 AM -03
baloo5-5.85.0-1pclos2021                      Sat 14 Aug 2021 10:58:07 AM -03
plasma-framework-5.85.0-1pclos2021            Sat 14 Aug 2021 10:58:06 AM -03
lib64kf5notifyconfig5-5.85.0-1pclos2021       Sat 14 Aug 2021 10:58:06 AM -03
kdelibs4support-5.85.0-1pclos2021             Sat 14 Aug 2021 10:58:06 AM -03
kdegraphics-mobipocket-21.08.0-1pclos2021     Sat 14 Aug 2021 10:58:06 AM -03
purpose-5.85.0-1pclos2021                     Sat 14 Aug 2021 10:58:05 AM -03
libkexiv2-21.08.0-1pclos2021                  Sat 14 Aug 2021 10:58:05 AM -03
libkdcraw-21.08.0-1pclos2021                  Sat 14 Aug 2021 10:58:05 AM -03
lib64kf5threadweaver5-5.85.0-1pclos2021       Sat 14 Aug 2021 10:58:05 AM -03
lib64kaccounts2-21.08.0-1pclos2021            Sat 14 Aug 2021 10:58:05 AM -03
lib64dav1d5-0.9.1-1pclos2021                  Sat 14 Aug 2021 10:58:05 AM -03
lib64avif11-0.9.1-2pclos2021                  Sat 14 Aug 2021 10:58:05 AM -03
lib64attica5-5.85.0-1pclos2021                Sat 14 Aug 2021 10:58:05 AM -03
kimageformats-5.85.0-1pclos2021               Sat 14 Aug 2021 10:58:05 AM -03
kcmutils-5.85.0-1pclos2021                    Sat 14 Aug 2021 10:58:05 AM -03
kaccounts-providers-21.08.0-1pclos2021        Sat 14 Aug 2021 10:58:05 AM -03
kaccounts-integration-21.08.0-1pclos2021      Sat 14 Aug 2021 10:58:05 AM -03
clang-12.0.1-2pclos2021                       Sat 14 Aug 2021 10:58:04 AM -03
lib64zip5-1.8.0-1pclos2021                    Sat 14 Aug 2021 10:58:02 AM -03
lib64aom3-3.1.2-1pclos2021                    Sat 14 Aug 2021 10:58:02 AM -03
ktexteditor-5.85.0-1pclos2021                 Sat 14 Aug 2021 10:58:02 AM -03
kparts-5.85.0-1pclos2021                      Sat 14 Aug 2021 10:58:02 AM -03
kio-5.85.0-1pclos2021                         Sat 14 Aug 2021 10:58:02 AM -03
kdeclarative-5.85.0-1pclos2021                Sat 14 Aug 2021 10:58:02 AM -03
libkipi-21.08.0-1pclos2021                    Sat 14 Aug 2021 10:58:01 AM -03
lib64syntaxhighlighting5-5.85.0-1pclos2021    Sat 14 Aug 2021 10:58:01 AM -03
lib64kf5pty5-5.85.0-1pclos2021                Sat 14 Aug 2021 10:58:01 AM -03
kwayland-5.85.0-1pclos2021                    Sat 14 Aug 2021 10:58:01 AM -03
ktextwidgets-5.85.0-1pclos2021                Sat 14 Aug 2021 10:58:01 AM -03
kpackage-5.85.0-1pclos2021                    Sat 14 Aug 2021 10:58:01 AM -03
kdoctools-5.85.0-1pclos2021                   Sat 14 Aug 2021 10:58:01 AM -03
kactivities5-stats-5.85.0-1pclos2021          Sat 14 Aug 2021 10:58:01 AM -03
lib64kf5sonnetui5-5.85.0-1pclos2021           Sat 14 Aug 2021 10:58:00 AM -03
mesa-21.2.0-3pclos2021                        Sat 14 Aug 2021 10:57:59 AM -03
solid-5.85.0-1pclos2021                       Sat 14 Aug 2021 10:57:55 AM -03
lib64kf5sonnetcore5-5.85.0-1pclos2021         Sat 14 Aug 2021 10:57:55 AM -03
lib64kf5bookmarks5-5.85.0-1pclos2021          Sat 14 Aug 2021 10:57:55 AM -03
kxmlgui-5.85.0-1pclos2021                     Sat 14 Aug 2021 10:57:55 AM -03
kwallet-5.85.0-1pclos2021                     Sat 14 Aug 2021 10:57:55 AM -03
kiconthemes-5.85.0-1pclos2021                 Sat 14 Aug 2021 10:57:55 AM -03
kglobalaccel-5.85.0-1pclos2021                Sat 14 Aug 2021 10:57:55 AM -03
kfilemetadata5-5.85.0-1pclos2021              Sat 14 Aug 2021 10:57:55 AM -03
kactivities5-5.85.0-1pclos2021                Sat 14 Aug 2021 10:57:55 AM -03
lib64kitemviews5-5.85.0-1pclos2021            Sat 14 Aug 2021 10:57:54 AM -03
lib64kf5jobwidgets5-5.85.0-1pclos2021         Sat 14 Aug 2021 10:57:54 AM -03
lib64kf5guiaddons5-5.85.0-1pclos2021          Sat 14 Aug 2021 10:57:54 AM -03
lib64kf5crash5-5.85.0-1pclos2021              Sat 14 Aug 2021 10:57:54 AM -03
lib64kf5completion5-5.85.0-1pclos2021         Sat 14 Aug 2021 10:57:54 AM -03
lib64kcodecs5-5.85.0-1pclos2021               Sat 14 Aug 2021 10:57:54 AM -03
kservice-5.85.0-1pclos2021                    Sat 14 Aug 2021 10:57:54 AM -03
knotifications-5.85.0-1pclos2021              Sat 14 Aug 2021 10:57:54 AM -03
kconfigwidgets-5.85.0-1pclos2021              Sat 14 Aug 2021 10:57:54 AM -03
kauth-5.85.0-1pclos2021                       Sat 14 Aug 2021 10:57:54 AM -03
lib64karchive5-5.85.0-1pclos2021              Sat 14 Aug 2021 10:57:53 AM -03
kwindowsystem-5.85.0-1pclos2021               Sat 14 Aug 2021 10:57:53 AM -03
kwidgetsaddons-5.85.0-1pclos2021              Sat 14 Aug 2021 10:57:53 AM -03
ki18n-5.85.0-1pclos2021                       Sat 14 Aug 2021 10:57:53 AM -03
kdbusaddons-5.85.0-1pclos2021                 Sat 14 Aug 2021 10:57:53 AM -03
kcoreaddons-5.85.0-1pclos2021                 Sat 14 Aug 2021 10:57:53 AM -03
kconfig-5.85.0-1pclos2021                     Sat 14 Aug 2021 10:57:53 AM -03
llvm-12.0.1-1pclos2021                        Sat 14 Aug 2021 10:57:52 AM -03
lib64xcrypt1-4.4.25-1pclos2021                Sat 14 Aug 2021 10:57:52 AM -03
glibc-2.33-9pclos2021                         Sat 14 Aug 2021 10:57:52 AM -03
--------------------------- Live session ------------------------------------
scrot-1.5-1pclos2021                          Mon 09 Aug 2021 07:21:06 PM -03
neofetch-7.1.0-1pclos2020                   * Mon 09 Aug 2021 07:21:06 PM -03
lib64giblib1-1.2.4-3pclos2021                 Mon 09 Aug 2021 07:21:06 PM -03
caca-utils-0.99-0.beta19.1pclos2018           Mon 09 Aug 2021 07:21:06 PM -03
bind-utils-9.10.8.P1-1pclos2019               Mon 09 Aug 2021 07:21:06 PM -03
-----------------------------------------------------------------------------
lm_sensors-3.6.0-2pclos2021                 * Mon 09 Aug 2021 06:39:59 PM -03
lib64rrdtool4-1.3.8-5pclos2013                Mon 09 Aug 2021 06:39:59 PM -03
-----------------------------------------------------------------------------
tolua++-1.0.93-2pclos2019                     Mon 09 Aug 2021 06:39:31 PM -03
lua5.3-5.3.5-2pclos2021                       Mon 09 Aug 2021 06:39:31 PM -03
conky-1.12.2-1pclos2021                     * Mon 09 Aug 2021 06:39:31 PM -03
lib64ircclient-1.6-1pclos2012                 Mon 09 Aug 2021 06:39:07 PM -03
---------------------------------- ISO --------------------------------------
kernel-devel-5.13.7-pclos2-1-1pclos2021       Sun 01 Aug 2021 02:01:36 AM -03
kernel-5.13.7-pclos2-1-1pclos2021             Sun 01 Aug 2021 02:01:08 AM -03
mylivecd-0.9.13-8pclos2021                    Sun 01 Aug 2021 02:00:19 AM -03
lib64pcre2_0-10.37-1pclos2021                 Sun 01 Aug 2021 01:59:57 AM -03
x11-driver-video-amdgpu-21.0.0-1pclos2021     Fri 30 Jul 2021 08:36:56 PM -03
getvirtualbox-6.1.26-1pclos2021               Fri 30 Jul 2021 08:36:56 PM -03
(...)
net-tools-1.60-22pclos2011                    Fri 12 Aug 2011 09:28:08 PM -03
update-alternatives-1.9.0-1pclos2011          Fri 12 Aug 2011 09:26:59 PM -03
multiarch-utils-1.0.13-1pclos2011             Fri 12 Aug 2011 08:54:28 PM -03
-----------------------------------------------------------------------------

Observe (acima):

A mudança no formato das horas, na parte referente ao dia 21 (que só acrescentei à lista, acima, após o dia 23).

A demora de mais de 5 minutos entre a instalação do primeiro e do segundo pacote de revisão de Kernel — causada, em parte, pela atualização do Grub (antes de desabilitar os_prober).

O fato de que o pacote “kernel-latest” não foi instalado com as dependências que pediu. — Tive de pedir sua instalação outra vez, depois delas — com outra demora de mais de 6 minutos ao atualizar o Grub (11:14~11:20).

Uso de Memória RAM (1)

Agendamento de tarefa pelo cronie

18 Agosto - Agendei a execução de um script 10 minutos após cada inicialização do PCLinuxOS:

@reboot sleep 600; bash RAM.sh

Esse era meu recurso para registrar informações do /proc/meminfo — para mais tarde calcular o uso inicial de Memória RAM de cada distro.

Através dele, pude confirmar que a nova instalação do PCLinuxOS KDE Darkstar recuperou (com vantagem) certa “leveza” que a instalação antiga tinha perdido, depois que mexi demais nela, em Março do ano passado:

Uso inicial de Memória RAM na antiga instalação do PCLinuxOS

Até 1º Agosto (gráfico acima), o uso inicial de Memória RAM pela antiga instalação do PCLinuxOS ficava acima de 900 MiB — devido a uma configuração esquisita (UXA) que fiz em Março 2020.

Uso de Memória RAM na nova instalação do PCLinuxOS

Na nova instalação (gráfico acima: 18 Agosto), o uso de Memória RAM pelo PCLinuxOS se reduziu em mais de 100 MiB.

Vale lembrar que minha antiga instalação era da ISO PCLinuxOS “normal” — enquanto a nova instalação é da ISO Darkstar, com um KDE mais “enxuto”.

Só alguns dias depois, percebi que as 4 distros “systemd-free” aparecem (acima) como as que usam menos Memória RAM. — Existe aí certa contribuição do acaso, pois algumas diferenças são tão pequenas, que basta a flutuação de 1 segundo (+/-25 MiB) para inverter as posições entre Slackware, Arch, Neon, Mint e Manjaro, por exemplo. — Enfim, vale notar que essas 4 distros “systemd-free” se caracterizam por certa frugalidade, que me parece o principal motivo de seu menor uso de Memória RAM.

Limpeza da pasta /home

21 Agosto - No pouco tempo em que usei a nova instalação do PCLinuxOS sem uma partição /home separada, evitei fazer muitas configurações, e removi todas as capturas de tela para um Pendrive. — Por isso, a subpasta /home/USER/ não acumulou mais do que uns 35 MiB em 447 arquivos e 81 subpastas (em sua maioria, ocultas).

Agora, a subpasta /home/USER/ é inacessível pelo PCLinuxOS — pois /home se tornou um link para a partição Home6 — por isso, encerrei a sessão, fui para o Mageia e usei o Midnight-Commander (mc), como root, para deletar a antiga subpasta Linux6/home/USER/.

O espaço liberado na partição-raiz do PCLinuxOS foi irrisório — coisa de uns 100 MiB (o espaço ocupado baixou de 7,79 GiB para 7,68 GiB) — mas não havia motivo para manter uma subpasta que, além de inacessível, se tornou inútil.

Ok, eu devia ter copiado, pelo menos, o arquivo bash_history. — Senti falta dele, depois.

Com a reativação do blur, o Menu volta a ser legível na frente do Conky

15:00 - Não faria nenhum sentido eu desativar o blur do Plasma — uma das glórias da humanidade — por isso, imagino que se tenha desabilitado em consequência de alguma das fatídicas futricagens que tentei em Março 2020.

Seja como for, essa “consequência” ficou na antiga partição Home6 — e ao incluí-la no /etc/fstab da nova instalação, veio com as demais configurações.

Mas agora, nada impede o blur. — Bastou localizá-lo no KDE System Settings e ativar.

A transparência do tema Maia transparent é bonita — mas sem o Blur, atrapalha o dia-a-dia.

Formatos regionais

Datas Relativas e Absolutas no Dolphin

23 Agosto - No Dolphin, me incomodavam as datas na forma de “ontem”, ou “há meia hora”, ou “agora mesmo”. — O que preciso, é ver data, hora e minuto em que cada arquivo foi modificado.

Para isto, encontrei a solução nas configurações do próprio Dolphin: — Bastou trocar o “estilo” de data — de “Relativo” para “Absoluto, nas configurações do modo “Detailed View".

Essa é uma opção que nunca notei — talvez porque as outras distros já venham com o Dolphin configurado para exibir datas no estilo “Absoluto”. — Há várias coisas, no universo KDE, cuja existência só me chama atenção quando alguma distro vem configurada de um modo diferente das outras.

Ficou o probleminha de “12:01 AM” ser noite escura, e “6:00 PM” no final da tarde — coisas mais abstrusas do que subtrair XXVIII de L.

Configurando Idioma pelo Centro de Controle

6:35 - Consegui solucionar este probleminha do formato das horas, apenas mudando a configuração de Idioma, de en_US para en_UK, no PCLinuxOS Control Center — e finalmente obtive o “formato 24 horas” no Dolphin, com zeros à esquerda para manter os números alinhados na coluna (o que ajuda muito).

Essa intervenção demorou apenas 3 minutos, e com certeza não “adicionei” nenhum “Idioma” ou “Tradução”. — Não houve nenhuma pergunta sobre “adicionar”, não houve download explícito (o contador do Conky acumulou 3,4 KiB, o que mal dá para o ping normal de 3 minutos), e não percebi alteração no uso de espaço em disco (7,67 GiB). — Apenas alterei uma “configuração” (afinal, o PCLinuxOS já vem em Inglês. Bastava trocar o “sotaque”, do Texas para Londres).

Em 27 Dezembro 2017, quando de fato instalei uma “tradução” (Português Brasileiro) pelo Localization Manager (Add Locale), documentei um processo radicalmente diferente, com várias etapas e opções, numa sucessão de janelas grandes e pequenas, um download de 33 MiB e aumento de ocupação de disco, de 7,03 GiB até 7,15 GiB (depois reduzido para 7,11 GiB, ao deletar o cache de pacotes). — No final, ainda recebi o conselho de fazer mais alguma coisa no LibreOffice (apareceu até mensagem na minha pasta pessoal, para me orientar nisso) — e a seguir, fui conduzido às configurações de Fuso horário e NTP, e às configurações do Teclado. Por fim, o Add Locale afirmou que “nós vamos reinicializar para ativar as mudanças".

Com essas 2 alterações, mínimas, terminaram meus problemas de “regionalização híbrida” — Idioma Inglês, Formatos Britânicos; Teclado ABNT2; Fuso horário BRT. — Depois disso, o bash também eliminou “AM” e “PM”; e passou a colocar o dia antes do mês:

Antes: — Sat Jul 10 07:33:02 PM -03 2021
Agora: — Mon 23 Aug 17:08:06 -03 2021

No Relógio e no Conky, eu já tinha configurado manualmente o formato das datas.

Hostname

Mudança do Hostname no PCLinuxOS

12:00 - Para mudar o Hostname da máquina, substituí “localhost.localdomain” por “Linux6” em /etc/hosts e em/etc/sysconfig/network — conforme a dica do Tex no Forum.

Em distros Debian, o caminho é um pouco diferente — e com SystemD, pode-se até usar um atalho para, simplesmente, ignorar os arquivos do sistema — um must!.

Uso de Memória RAM (2)

Alterações no Conky para exibir o uso de Memória RAM

13:00 - Finalmente, organizei um modo de exibir o cálculo “novo” de Memória Usada.

Esse cálculo “novo”, na verdade, foi proposto ou subscrito por Linux Torvalds há mais de 7 anos (2014) — quando se introduziu no Kernel 3.14 um campo “MemAvailable”, que pode ser lido em /proc/meminfo, sem necessidade de privilégios especiais:

MemTotal - MemAvailable = “Mem Used”

Só começou a ser adotado pelo Conky em 2020; e pelo inxi e pelo Screenfetch em 2021 — mas algumas distros ainda usam versões anteriores desses pacotes (com outros cálculos), o que invalida usá-los para comparar distros diferentes. — Daí, meu interesse em automatizar e exibir esse cálculo “novo” no Conky, em uma coluna com os números das demais ferramentas.

Para exibir o cálculo “novo” no Conky, improvisei um bash-script “MemInfo.sh”, ainda bastante tosco — a partir de uma linha de comando awk encontrada na internet — afinal, TI está muito longe da minha área:

MEM_TOTAL=$(awk '/MemTotal/ { printf $2 }' /proc/meminfo); \
MEM_AVAIL=$(awk '/MemAvailable/ { printf $2 }' /proc/meminfo); \
MEM_USED_KILO="$(($MEM_TOTAL-$MEM_AVAIL))"; \
MEM_USED_BYTES_X_1000="$(($MEM_USED_KILO*1000))";\
echo "                                  $(($MEM_USED_BYTES_X_1000/1048576))" MiB > MemInfo.txt
echo "                                  $(($MEM_USED_KILO/1024))" MiB >> MemInfo.txt

Resolvi exibir 2 resultados desse cálculo “novo” — um que me parece o mais “correto” (até que encontre uma boa explicação em contrário) — e outro que parece ser o adotado, “na prática”, pelas versões mais recentes do Conky e do Screenfetch:

1) No primeiro, o número obtido é multiplicado por 1.000 — pois o /proc/meminfo é muito claro ao dizer que suas informações estão em “kB”, com “k” minúsculo, indicativo explícito de “quilo” no Sistema Métrico Internacional (SI) — e em seguida dividido por 1.048.576 (1.024 x 1024), para converter em Mebibytes (MiB).
2) No outro, o número é simplesmente dividido por 1.024. — Embora me pareça “tecnicamente incorreto”, este segundo resultado é o que tem igualado, quase com exatidão, o apresentado pelas versões mais recentes do Conky e do Screenfetch.

Esse script é executado pela configuração do segundo Conky — e salva o resultado em um arquivo-texto de 2 linhas — que o Conky exibe na tela:

/proc/meminfo
${execi 10 bash MemInfo.sh; cat MemInfo.txt}

Alterei este segundo Conky para se atualizar a cada 10 segundos — o que evita alterações súbitas ao disparar a captura de tela. — Por isso, o número “Conky (Mem)” indicado nele pode diferir do indicado no primeiro Conky, que se atualiza a cada 1 segundo

Para reduzir a frequência de atualização do segundo Conky, movi o gráfico de Disk I/O para o primeiro Conky — afinal, pode ser interessante acompanhar de perto a leitura e escrita em disco, durante algumas atividades (backups, recebimento de fotos pelo KDE Connect, downloads, atualizações). — No segundo Conky, deixei apenas coisas que se atualizam a cada 10 segundos, ou mesmo a cada 600 segundos (versões do KDE, Qt, Frameworks, aplicativos KDE).

Fontes TTF

Instalação de uma fonte TTF no PCLinuxOS

24 Agosto - Na seção de gerenciamento de fontes do Centro de Controle do PCLinuxOS, o botão “Get Windows Fonts” permite localizar e instalar rapidamente fontes TTF — desde que encontre uma instalação do Windows na máquina. — Como não tenho Windows, recebi uma mensagem de erro.

Então cliquei no botão “Import” e abri uma pasta onde eu já tinha reunido uma coleção de fontes do CorelDraw e do pacote ttf-mscorefonts-installer (.deb). — Nesse momento, precisei instalar apenas Zapf Dingbats, que não lembro de onde trouxe.

Grub & Synaptic

Instalação do “kernel-latest” e suas dependências

O pacote “kernel-latest” é um modo de automatizar as atualizações (revisões), bem como a instalação de novas versões — pois o PCLinuxOS deixa essas escolhas por conta do usuário.

Como já existia uma revisão mais atual nos repositórios, foi automaticamente incluída como dependência.

Atividade excessiva de CPU, aquecimento e demora

O processo demorou 6 minutos (11:05~11:11), com intensa atividade de CPU e aquecimento em 1 ou 2 núcleos ao longo de quase todo esse tempo — e no final recebi uma mensagem de que “nem todas as mudanças foram aplicadas”:

Preparing kernel 5.13.10-pclos1 for module build:
(This is not compiling a kernel, just preparing kernel symbols)
Storing current .config to be restored when complete
Running Generic preparation routine
make clean....
using /boot/config-5.13.10-pclos1
make oldconfig....
make prepare....

Building module:
cleaning build area....
make -j6 KERNELRELEASE=5.13.10-pclos1 -C /lib/modules/5.13.10-pclos1/build M=$(pwd) SKIP_STACK_VALIDATION=1....
cleaning build area....
cleaning kernel tree (make clean)....

DKMS: build Completed.

wl.ko.xz:
 - Installation
   - Installing to /lib/modules/5.13.10-pclos1/kernel/3rdparty/broadcom-wl/

depmod.....

DKMS: install Completed.

Preparing kernel 5.13.10-pclos1 for module build:
(This is not compiling a kernel, just preparing kernel symbols)
Storing current .config to be restored when complete
Running Generic preparation routine
make clean.....
using /boot/config-5.13.10-pclos1
make oldconfig....
make prepare....

Building module:
cleaning build area....
export IGNORE_CC_MISMATCH=1;'make' -j6 SYSSRC=/lib/modules/5.13.10-pclos1/build modules SKIP_STACK_VALIDATION=1.........^Cerror: %post(kernel-devel-5.13.10-pclos1-1-1pclos2021.x86_64) scriptlet failed, signal 2

Not all changes and updates succeeded. For further details of the the failure, please expand the 'terminal' panel below.

Esta mensagem deveria incluir a saída da atualização do Grub — com a tradicional lista das distros detectadas — mas isso não aconteceu.

Tentando entender o que havia acontecido, percebi que:

O “kernel-latest” não foi instalado — só a nova revisão do Kernel (sua dependência).

O Synaptic não incluiu em seu histórico a instalação da revisão de Kernel. — No entanto, os 2 pacotes aparecem na listagem $ rpm -qa --last — distanciados, um do outro, por 5 minutos (11:05 e 11:10).

Uso inútil de CPU (e de tempo) pelo Synaptic, a cada operação envolvendo Kernel

Mandei de novo instalar o “kernel-latest” (agora, sem dependências) e finalmente o processo concluiu com sucesso, após 6 minutos de intensa atividade de CPU, aquecimento etc.

Houve uma mensagem de falha do Synaptic — mas dessa vez ele registrou a instalação em seu histórico — e no final apresentou a saída da atualização do Grub:

Commit Log for Sat Aug 14 11:14:12 2021 ---> Kernel-Latest ---> Try again:

Installed the following packages:
kernel-latest (5.13.10.pclos1-1pclos2021)
----------------------------------------------------------------------------------
(synaptic:6442): GLib-CRITICAL **: 11:14:13.180: g_child_watch_add_full: assertion 'pid > 0' failed
Preparing
%% 100.000000
kernel-latest-5.13.10.pclos1-1pclos2021
Generating grub configuration file ...
Found theme: /boot/grub2/themes/pclinuxos/theme.txt
Found linux image: /boot/vmlinuz-5.13.10-pclos1
Found initrd image: /boot/initrd-5.13.10-pclos1.img
Found linux image: /boot/vmlinuz-5.13.7-pclos2
Found initrd image: /boot/initrd-5.13.7-pclos2.img
Found void on /dev/sda10
Found Manjaro Linux (21.1.0) on /dev/sda11
Found Slackware 14.2 x86_64 (post 14.2 -current) on /dev/sda12
Found MX 19.4 patito feo (19.4 ) on /dev/sda13
Found openSUSE Tumbleweed on /dev/sda2
Found Arch Linux (rolling) on /dev/sda3
Found Debian GNU/Linux 11 (bullseye) on /dev/sda4
Found Fedora 34 (KDE Plasma) on /dev/sda5
Found KDE neon User Edition 5.22 (20.04) on /dev/sda6
Found PCLinuxOS on /dev/sda7
Found Mageia 8 (8) on /dev/sda8
Found Linux Mint 20 Ulyana (20) on /dev/sda9
done

Successfully applied all changes. You can close the window now.
----------------------------------------------------------------------------------

Também notei que, embora tenha detectado o openSUSE, não o incluiu no Menu do Grub — mas isso acontece com o Grub de várias distros. — Poucas conseguem gerar as “entradas” para o openSUSE, e várias ainda geram entradas incompletas para o Arch / Manjaro.

Atualização do Grub rápida e “indolor”, por comando CLI

Enfim, vale notar que a atualização pelo comando # grub2-mkconfig se fazia em apenas 32 segundos — sem muito uso de CPU e sem aumento de temperatura:

# date; time grub2-mkconfig -o /boot/grub2/grub.cfg; date
Sat Aug 14 02:03:12 PM -03 2021
Generating grub configuration file ...
Found theme: /boot/grub2/themes/pclinuxos/theme.txt
Found linux image: /boot/vmlinuz-5.13.10-pclos1
Found initrd image: /boot/initrd-5.13.10-pclos1.img
Found linux image: /boot/vmlinuz-5.13.7-pclos2
Found initrd image: /boot/initrd-5.13.7-pclos2.img
Found void on /dev/sda10
Found Manjaro Linux (21.1.0) on /dev/sda11
Found Slackware 14.2 x86_64 (post 14.2 -current) on /dev/sda12
Found MX 19.4 patito feo (19.4 ) on /dev/sda13
Found PCLinuxOS on /dev/sda14
Found openSUSE Tumbleweed on /dev/sda2
Found Arch Linux (rolling) on /dev/sda3
Found Debian GNU/Linux 11 (bullseye) on /dev/sda4
Found Fedora 34 (KDE Plasma) on /dev/sda5
Found KDE neon User Edition 5.22 (20.04) on /dev/sda6
Found Mageia 8 (8) on /dev/sda8
Found Linux Mint 20 Ulyana (20) on /dev/sda9
done

real    0m32.407s
user    0m12.001s
sys     0m13.393s
Sat Aug 14 02:03:44 PM -03 2021

Esse comportamento do Synaptic também acontece em outras distros — já registrei vários casos no Kubuntu, por exemplo.

Não lembro outros casos com aplicativos GUI de gerenciamento ou atualização de pacotes, pois nos últimos anos tenho feito isso sempre por comandos CLI — exceto nas distros que têm Synaptic.

Mas já flagrei o Plasma-Discover usando CPU intensamente e aquecendo — só de ser aberto — e em alguns momentos, o próprio KDE System Settings.

Enfim, já vi Psensor gerar esses problemas — e bastava minimizá-lo, para tudo se acalmar de novo.

Em resumo, me parece um problema do apt ou do Synaptic — e como não sei examiná-los ou corrigi-los, procuro contornar o problema: — Dar a volta na árvore, focando na floresta.

Grub & Draklive-install

xxx

A instalação do PCLinuxOS se completou em 4 minutos (17:36~17:40 UTC) — incluindo a formatação da partição — e apresentou a primeira tela de opções de bootloader:

Grub2 com menu de texto ou gráfico

Dispositivo de boot

Tempo de espera

Opções avançadas — Habilitar ACPI, SMP, APIC, APIC local

xxx

Após aceitar as opções sugeridas e mandar prosseguir, o Draklive-install pôs em marcha todas as ferramentas de detecção de outros sistemas operacionais — grub-mount, os-prober etc. — durante 5 minutos (17:41~17:46); e por fim chegou à tela onde eu poderia... desabilitar a detecção de outros sistemas operacionais!

No campo superior, já sugeriu tornar Arch Linux a “entrada” padrão.

Nas opções avançadas, eu também podia mandar que não instalasse o carregador de boot — nem em partição EFI, nem em trilha MBR.

No meu antigo hardware (2 x Core2 Duo com 4 GB RAM), o Draklive-install quebrava antes de chegar a essa tela, para poder desabilitar a detecção de outras distros (neste caso, problema do Drakslive-install, não do Synaptic). — Em 2017, a solução foi escolher “Grub (legacy)”. — Em 2019, esta opção já não existia, e a solução foi desplugar 3 HDDs, de modo que o Grub só encontrasse outras 2 distros, e assim não quebrasse o Draklive-install. — No meu hardware atual, nem isso eu poderia fazer, pois todas as distros estão no mesmo SSD.

xxx

Desabilitei a detecção de outras distros (Probe Foreign OS), cliquei em “Finish”.

xxx

Por mais 5 minutos (17:49~17:54), o Draklive-Install tornou a mobilizar todos os recursos de detecção de outras distros — grub-mount, os-prober etc. — e finalmente deu por encerrada a instalação.

Ufa! — Pelo menos, neste hardware mais robusto o Drakelive-install não quebrou.

— … ≠ • ≠ … —

Mandrake / Mandriva

PC desktop UEFI / GPT

Manjaro - instalação e configuração

noreply@blogger.com (Mboaba) — Tue, 27 Apr 2021 10:21:00 +0000

Manjaro KDE instalado e configurado

• Resolvi fazer essa instalação do Manjaro — expressamente para “brincar” um pouco com o Pamac, AUR e Flatpak — motivado pelo tutorial “Instalei o Manjaro. E agora?”, do Rodrigo_Chile (ChileDJ), no blog Manjariando.

Índice

Instalação
Grub
Pós-instalação
Tutorial

1º Passo - Atualização inicial
2º Passo - Instalar pacotes de Idiomas e Kernels
3º Passo - Alterar o Grub para ser exibido
4º Passo - Configurar o Pamac (7 abas)
Bônus - Repositório “Manjariando”

Experiências anteriores (2017 e 2018)

Instalação

Opções de boot do Live Manjaro

Baixei a imagem ISO manjaro-kde-21.0.2-210419-linux510 pelo KTorrent, fiz a verificação pelo sha1sum e “queimei” pelo K3b em DVD, para guardar.

No Menu de Boot da sessão Live, escolhi o fuso horário do centro-sul do Brasil (BRT), Teclado ABNT2 e idioma Inglês britânico (en_GB).

Tentativa de desabilitar os_prober

Tentei desabilitar os_prober em /etc/default/grub, logo no início da sessão Live — mas não fez efeito durante a instalação.

Monitoramento do processo de instalação do Manjaro

Desde o momento em que iniciei o Instalador, um processo grub-mount ocupou 100% de um núcleo da CPU — e assim prosseguiu mesmo depois que fechei o Instalador, no final de tudo.

Com isso, durante os 10 minutos da instalação efetiva (Slideshow) houve sempre pelo menos 1 núcleo com temperatura acima de 70ºC — o que já me causou dificuldades em 2018, quando eu tinha um processador de apenas 2 núcleos. — Mas isso não é exclusividade do Manjaro.

Ver “Experiências anteriores (2017 e 2018)”, no final

Definições de localização do Manjaro

O primeiro passo da instalação é definir o Fuso horário, o Idioma e os Formatos regionais de números e datas. — O Instalador ignora as opções da sessão Live e retoma os padrões de Nova Iorque / Estados Unidos. — Ao mudar o Fuso horário para BRT, os Formatos de números e datas se alteram automaticamente, mas isso pode ser alterado à parte.

Opções de particionamento ao instalar o Manjaro

Na definição das partições, são oferecidas 4 opções — instalar “ao lado” de outro sistema, substituir uma partição, apagar o disco inteiro, ou fazer manualmente o particionamento. — Todas essas opções vêm desmarcadas, o que impede de avançar sem prestar atenção.

Escolhi “particionamento manual” — porque estou acostumado a essa opção. — Eu só precisava escolher 2 partições, “Editar” cada uma delas para criar os respectivos pontos de montagem, e formatar a partição-raiz:

├─sda11   30 G  Linux10    (Format)
├─sdb11   13 G   Home10    (Keep)

Ao concluir, fui advertido de que a partição EFI não estava escolhida. — Prossegui assim mesmo, pois meu “Menu de inicialização” é controlado pelo Grub do openSUSE Tumbleweed.

Dessa vez, o Instalador não adicionou automaticamente a partição Swap existente. — Mais tarde, copiei a linha do Swap do /etc/fstab de outra distro (Arch) — e montei com # swapon --all.

Na etapa “Usuários”, defini o nome do sistema (Linux10), habilitei o Login automático, e senha separada para o superusuário (root).

Atividade de CPU com grub-mount, mesmo após o fim da instalação

Após conferir o Resumo das configurações, cliquei para iniciar a instalação efetiva no hardware, que se realizou em 10 minutos — das 18:53 às 19:03 — sempre com pelo menos um processo grub-mount / os-prober consumindo quase 100% de um núcleo de CPU e mantendo sua temperatura acima de 70ºC.

Grub

Atualização do Grub do openSUSE

Ao reiniciar o computador, carreguei o openSUSE Tumbleweed — cujo Grub controla meu “Menu de inicialização” — e que em 1 minuto detectou todas as outras distros instaladas em dualboot.

É o único Grub que gera entradas capazes de carregar o Arch Linux e o Manjaro. — O Grub do Arch ou do Manjaro também consegue, claro — mas não costumava detectar ou gerar entradas corretas para carregar o openSUSE (e nunca mais verifiquei se já consegue).

Correção manual da entrada do Arch no Grub do Mageia (2020)

Como “reserva”, em caso de emergência, o Grub do Mageia também consegue gerar entradas corretas para carregar o openSUSE — mas suas entradas do Arch e do Manjaro precisam ser corrigidas manualmente, para adicionar o caminho (PATH) para o initramfs.

Por isso, em 2017 eliminei o Manjaro após instalar o Arch, de modo que bastasse 1 busca-e-troca global automática (Replace All), que o editor interno do Midnight-Commander (mcedit) “lembra”, sem exigir nova digitação a cada vez. — Agora, com Arch e Manjaro, serão 2 substituições diferentes, a serem decididas caso-a-caso, no olho. — Felizmente, há muito tempo não tenho emergências que me exijam recorrer ao Grub do Mageia.

Pós-instalação

Plasma pré-configurado por herança da /home

Com a preservação da /home que tinha sido do Slackware by AlienBOB, o Manjaro já abriu com papel de parede, Painel personalizado (faltando o lançador do Chromium), teclas de atalho do KDE Spectacle, cores noturnas, histórico do bash (com datação), montagem automática de partições adicionais, sessão do Kate com abertura automática de vários arquivos, preferências do VLC, e até os widgets de clima (Weather) e de fases da lua (Gealach).

Entre 20:00 e 23:00, atualizei os 2 pacotes indicados pela notificação, instalei alguns pacotes mais urgentes — gnome-screenshot, Conky, LibreOffice, KWrite, pcurses, hddtemp, qt5-xmlpatterns (para o widget Weather), neofetch, Calligra, Marble, Gimp, KRename, KRuler, KDiff3, xsane, speedtest-cli, youtube-dl, npm, corona-cli etc. — e executei # sensors-detect para o Conky encontrar as Temperaturas dos núcleos da CPU.

Repassei as configurações no KDE System Settings, onde encontrei algumas opções que tinham voltado ao padrão e tive de refazer. — Aproveitei para trocar o Tema Breeze pelo Breeze-Dark.

Instalei algumas fontes a partir de arquivos TTF locais e executei $ fc-cache -fv para reconhecê-las (não ficou no bash_history: 21:25).

Copiei para o /etc/fstab a linha de Swap do Arch e executei # swapon --all para ativá-lo.

Substituí o ícone do Slackware pelo do Manjaro no Menu.

Configuração básica do ambiente Plasma no Manjaro

Baixei do celular as fotos da instalação, pelo KDE Connect, e renomeei pelo KRename, no mesmo padrão “yyyy-MM-dd_HH-mm-ss” dos nomes das capturas de tela e da datação dos comandos no histórico do bash — o que facilita recuperar a cronologia:

                      $    1    echo 'export HISTTIMEFORMAT="%F_%H-%M-%S "' >> ~/.bashrc
2020-09-26   14:58    $    2    history
2021-02-28   12:53    $    4    echo 'export HISTTIMEFORMAT="%F_%H-%M-%S "' >> ~/.bashrc
...
2021-04-26   19:47    PrtScn    Manjaro Spectacle
2021-04-26   20:04    #    5    cat /var/log/pacman.log
2021-04-26   20:17    #    6    pacman-mirrors --country Brazil
2021-04-26   20:18    $    5    cat /etc/pacman.d/mirrorlist > mirrorlist_000.txt
2021-04-26   20:19    #    7    nano cat /etc/pacman.d/mirrorlist
2021-04-26   20:36    #   10    pacman -Syyu
2021-04-26   20:40    #   11    pacman -S kwrite
2021-04-26   20:40    #   12    pacman -S gnome-screenshot
2021-04-26   20:40    #   13    pacman -S conky
2021-04-26   20:42    #   15    pacman -S pcurses
2021-04-26   20:47    PrtScn    PrtScn-gnome-screenshot
2021-04-26   20:48    PrtScn    Shift-PrtScn-gnome-screenshot
2021-04-26   20:53    PrtScn    Conky-conf
2021-04-26   20:55    #   16    pacman -S hddtemp
2021-04-26   20:57    #   17    watch sensors
2021-04-26   20:57    #   18    sensors-detect
2021-04-26   21:15    PrtScn    Gealach settings
2021-04-26   21:17    PrtScn    Weather widget
2021-04-26   21:21    #   19    pacman -S qt5-xmlpatterns
2021-04-26   21:23    PrtScn    Fonts (+ $ fc-cache -fv)
2021-04-26   21:27    #   20    pacman -S neofetch
2021-04-26   21:28    PrtScn    hwmon
2021-04-26   21:34    PrtScn    Restart
2021-04-26   21:36    PrtScn    startup AutoLogin Conky
2021-04-26   21:37    PrtScn    Dolphin Previews
2021-04-26   21:43    #   21    pacman -S calligra
2021-04-26   21:46    #   22    pacman -S libreoffice
2021-04-26   21:54    PrtScn    /etc/fstab
2021-04-26   21:58    #   23    pacman -S marble
2021-04-26   21:59    #   24    swapon --all
2021-04-26   22:00    PrtScn    Dolphin Previews config
2021-04-26   22:04    PrtScn    Menu-icon
2021-04-26   22:08    PrtScn    kdeConnect - download Android photos
2021-04-26   22:11    #   26    pacman -S krename
2021-04-26   22:13    PrtScn    Dolphin open-folder-with - KRename, Filelight
2021-04-26   22:15    PrtScn    KSysguard - none PIM, Baloo, Akonadi
2021-04-26   22:15    PrtScn    KSysguard set 1’’ interval
2021-04-26   22:21    #   28    pacman -S speedtest-cli
2021-04-26   22:21    #   29    pacman -S youtube-dl
2021-04-26   22:24    #   30    pacman -S gimp
2021-04-26   22:27    #   32    pacman -S npm
2021-04-26   22:27    #   33    npm i -g corona-cli
2021-04-26   22:32    #   34    pacman -S kruler
2021-04-26   22:33    #   35    pacman -S kdesdk-thumbnailers
2021-04-26   22:34    #   36    pacman -S kdiff3
2021-04-26   22:35    #   37    pacman -S xsane
2021-04-26   22:50    PrtScn    KRename
2021-04-26   23:00    #   39    ip address show

Tutorial

Configuração do Manjaro, até abrir o Pamac

Depois de 3 anos usando o Arch, o Tutorial do RodrigoDJ me deu uma visão do Manjaro, muito clara e bem estruturada em torno do Pamac, que eu não tive nas 2 experiências anteriores (2017, 2018) — quando o Manjaro ainda vinha com o Octopi, e não com o Pamac:

1º Passo - Atualização inicial

Escolha dos mirrors
Alternativa: Pamac-CLI

2º Passo - Instalar pacotes de Idiomas e Kernels

Instalar mais 2 Kernels

3º Passo - Alterar o Grub para ser exibido
4º Passo - Configurar o Pamac (7 abas)

Número de downloads simultâneos
Frequência da verificação
Habilitar downgrade
Espelhos - já resolvido antes, por comando
Habilitar AUR

Verificar atualizações
Limpar espaço de compilações anteriores

Habilitar Snap
Habilitar Flatpak

Verificar atualizações

Cache do Pacman (não mexer agora)

Número de versões de pacotes a manter (3), para permitir downgrade

Remoção de pacotes órfãos — Disable "Software Mode"

Bônus - Repositório “Manjariando”

Nessa estruturação, concisa e clara, percebi a possibilidade de adaptar cada opção a qualquer outro “projeto”, personalizado, sem necessidade de me ater ao que é proposto. — Por exemplo, eu poderia habilitar apenas o AUR, de início, para testar e aprender mais — sem colocar em risco minha instalação do Arch Linux.

O que se segue, portanto, é apenas minha adaptação, numa fase inicial.

1º Passo - Atualização inicial

Edição do /etc/pacman.d/mirrorlist pelo nano

Embora focado no Pamac-GUI, o Tutorial começa por um comando simples do pacman — que pode ser executado em poucos segundos, antes de cada atualização — para escolher sempre os 5 espelhos com melhor resposta no momento, de modo a fazer o download das atualizações com a maior velocidade possível.

$ sudo pacman-mirrors -f5

Pessoalmente, prefiro outro caminho — escolher apenas os espelhos do Brasil, e em seguida editar o /etc/pacman.d/mirrorlist pelo nano para colocar no topo da lista o espelho que há vários anos tem se mostrado menos sujeito a falhas, em quase todas as minhas distros. — Faço isso só 1 vez, e nunca mais preciso me preocupar.

Mas só posso falar pela velocidade no “tronco” Brasília-SP-Curitiba — pois é possível que, para outros locais, outros espelhos apresentem melhor resposta:

# pacman-mirrors --country Brazil

::INFO Downloading mirrors from Manjaro
::INFO => Mirror pool: https://repo.manjaro.org/mirrors.json
::INFO => Mirror status: http://repo.manjaro.org/status.json
::INFO User generated mirror list
::------------------------------------------------------------
::INFO Custom mirror file saved: /var/lib/pacman-mirrors/custom-mirrors.json
::INFO Using default mirror file
::INFO Querying mirrors - This may take some time
  1.215 Brazil         : https://manjaro.c3sl.ufpr.br/
  1.306 Brazil         : http://linorg.usp.br/manjaro/
  0.552 Brazil         : https://www.caco.ic.unicamp.br/manjaro/
::INFO Writing mirror list
::Brazil          : https://www.caco.ic.unicamp.br/manjaro/stable
::Brazil          : https://manjaro.c3sl.ufpr.br/stable
::Brazil          : http://linorg.usp.br/manjaro/stable
::INFO Mirror list generated and saved to: /etc/pacman.d/mirrorlist

Atualização inicial do Manjaro, pelo pacman

Após descrever o uso do Pamac-GUI para atualizar o sistema, o Tutorial indica 2 alternativas de atualização por comandos CLI — o pacman, apenas para os repositórios oficiais — e o pamac, para todos os repositórios que estiverem habilitados no momento:

Official repositories:
$ sudo pacman -Syyuu

Official + AUR + ... :
$ pamac update --force-refresh

Nesse primeiro momento, me limitei ao pacman, que eu já estava acostumado a usar há 4 anos.

2º Passo - Instalar pacotes de Idiomas e Kernels

Controle das verificações e notificações de pacotes no Manjaro

Este passo tinha pouco interesse para mim — mas é um dos pontos altos que tornam o Manjaro particularmente amigável para um novo usuário.

Atualmente, não vejo motivo para mudar o Kernel padrão de cada distro (o 5.10 é LTS, com suporte até Dezembro 2026) — e a sugestão de instalar 3 Kernels diferentes (cada um com 2 ou 3 revisões) me parece um exagero, a menos que se tenha algum motivo muito especial, de hardware ou de tarefas fora do comum.

Como não jogo, não faço edição de vídeos pesados etc., há muitos anos planejo meu hardware de modo a reduzir dificuldades no Linux. — Por exemplo, no meu antigo PC, de 2009 a 2020:

      Mobo: P5KPL-AM-CKD-VISUM-SI, BIOS 0305 11/24/2008 - ASUSTeK
      iGPU: Intel Corporation 82G33/G31 Express Integrated Graphics Controller (rev 10)
Processors: 2 × Intel® Core™2 Duo CPU E7300 @ 2.66GHz
    Memory: 3,8 GiB of RAM

— e agora, desde 2020:

      Mobo: TUF B360M-PLUS GAMING/BR, BIOS 2401 03/22/2019 - ASUSTeK
      iGPU: Intel Corporation UHD Graphics 630 (Desktop)
Processors: 6 × Intel® Core™ i5-9400 CPU @ 2.90GHz
    Memory: 15.5 GiB of RAM

Pacotes de Idioma também não são uma necessidade urgente ou inquestionável. — Só porque configurei Idioma Inglês britânico + Teclado e Fuso horário do Brasil, o sistema “imagina” que eu queira instalar todos os pacotes de Ajuda, Hifenização, Verificação ortográfica desses 2 Idiomas (e também do Inglês norte-americano, que persistiu, como um padrão) — além das Traduções do Qt5, Firefox, Thunderbird (que não uso), LibreOffice e Manuais do Linux em 3 Idiomas!

Quero decidir com calma, porque isso representaria, no mínimo, mais downloads, a cada atualização.

Enfim, não compartilho a ansiedade de verificar atualizações a todo momento. — Minhas distros funcionam bem, com uma atualização semanal (bem documentada) — ou quando vou instalar novos pacotes, claro.

Para começar, neste 2º Passo me limitei a desabilitar a verificação de atualizações no Pamac-GUI (ícone em forma de Escudo) — e desabilitar a verificação de Kernels e pacotes de Idioma nas notificações no Manjaro Settings Manager (ícone retangular do Manjaro). — Esses 2 notificadores estão configurados (no System Tray) para exibição apenas quando houver motivo.

Uma vez desabilitados, não aparecem mais.

Itens comuns ao Manjaro Settings e ao System Settings

Porém, vale notar que o Manjaro Settings Manager reúne alguns recursos já tradicionais do KDE System Settings — com algumas modificações interessantes — e acrescenta outros, como o gerenciamento de Kernels e o gerenciamento de drivers no item “Hardware Configuration”.

Seus 7 itens aparecem no KDE System Settings, agrupados na seção “Manjaro” — mas quase todos também podem ser encontrados em suas seções tradicionais — Keyboard, em “Input Devices”; Languate Packs, Locale, Time & Date, em “Regional Settings”; e User Accounts, em “Users”, como nas demais distros.

O uso de ícones diferentes para os mesmos itens, em um e outro lugar, pode causar alguma confusão, e impedir que se perceba isso à primeira vista.

São 7 itens básicos para o iniciante, reunidos de modo simples e claro — e dotados de “capacidade de ação”, para detectar e avisar sobre coisas elementares, que o iniciante pode querer, mas ainda não sabe. — Apenas, não é o meu caso.

3º Passo - Alterar o Grub para ser exibido

Este passo altera a configuração original do Grub no Manjaro — “GRUB_TIMEOUT=0” e “GRUB_TIMEOUT_STYLE=hidden” — que leva o boot a carregá-lo automaticamente, sem passar pela exibição do Menu de inicialização — e o iniciante precisaria adivinhar que deve apertar determinada tecla, durante o boot, para ter acesso a outros Kernels, nas Opções Avançadas.

Esconder o Menu de inicialização é um padrão curioso — ótimo, talvez, para quem tem no Manjaro seu único sistema, e só deseja carregá-lo automaticamente, ao ligar o computador.

Na minha instalação, de fato encontro “GRUB_TIMEOUT_STYLE=hidden” — embora com “GRUB_TIMEOUT=5”.

Como não instalei a “chamada” do Manjaro na partição EFI, não tenho como testar seu Grub, e por isso, não sei se essa combinação também esconde o Menu de inicialização. Fica o registro.

4º Passo - Configurar o Pamac (7 abas)

Preferências do Pamac quanto ao repositório AUR

A exposição clara e bem ilustrada das funções do Pamac foi para mim uma revelação — pois nas 2 experiências anteriores conheci apenas o Octopi, que era o padrão anterior. — Além disso, naquelas épocas não pude contar com um Tutorial tão bem estruturado e esclarecedor.

As funcionalidades encontradas nas 7 abas nas “Preferências” do Pamac definem algumas das principais facilidades do Manjaro em relação ao Arch Linux, para um novo usuário.

Na primeira aba, a sugestão de reduzir o máximo de 4 downloads simultâneos (padrão) para apenas 1 de cada vez pode ser muito útil para quem tem uma conexão fraca, mas não é o meu caso, então, não mexi nisso.

Imagino que isso não afete o pacman, cujo padrão me parece ser de baixar 1 pacote de cada vez. — Por coincidência, justo nesses dias, foi introduzida no pacman a opção de downloads simultâneos — que ainda não testei.

A sugestão de aumentar a frequência de verificação de atualizações, de “a cada 6 horas” (padrão) para “a cada 1 hora”, vai contra a prática que adotei há alguns anos. Simplesmente desabilitei essas verificações. — Verifico as atualizações manualmente, por comandos, uma vez por semana, em geral aos Domingos (e antes de instalar novos pacotes, também, claro).

Na segunda aba, já estava ativada a opção de verificar se há espaço livre em disco, ao instalar ou atualizar pacotes, — mas encontrei desativadas as opções de remover dependências desnecessárias, de habilitar downgrade, e de ignorar atualizações de pacotes (a serem definidos pelo usuário). — Não alterei nada, a princípio.

Na terceira aba, onde se podem escolher os espelhos dos repositórios oficiais, o Pamac exibiu “Use mirrors fom: Brazil”, pois eu já havia feito essa alteração pelo comando # pacman-mirrors --country Brazil.

Nas abas seguintes (AUR, Snap, Flatpak), pude obter uma visão clara das opções envolvidas no uso de cada um desses tipos de pacotes. — Essas opções podem parecer óbvias a quem já se familiarizou com o uso deles, mas não para mim, que tenho lido bastante, mas ainda evito usá-los.

De qualquer modo, no momento, não alterei mais nada nessas abas. Apenas “reservei” esse conhecimento para a ocasião oportuna. — De fato, só 15 a 20 dias mais tarde, habilitei o AUR e a verificação de atualizações de pacotes do AUR no /etc/pamac.conf — onde as verificações automáticas já estavam desabilitadas na linha “RefreshPeriod = 0”:

### Pamac configuration file

## When removing a package, also remove those dependencies
## that are not required by other packages (recurse option):
#RemoveUnrequiredDeps

## How often to check for updates, value in hours (0 to disable):
RefreshPeriod = 0

## When no update is available, hide the tray icon:
#NoUpdateHideIcon

## When applying updates, enable packages downgrade:
#EnableDowngrade

## When installing packages, do not check for updates:
#SimpleInstall

## Allow Pamac to search and install packages from AUR:
EnableAUR

## Keep built packages from AUR in cache after installation:
#KeepBuiltPkgs

## When AUR support is enabled check for updates from AUR:
CheckAURUpdates

## When check updates from AUR support is enabled check for vcs updates:
#CheckAURVCSUpdates

## AUR build directory:
BuildDirectory = /var/tmp

## Number of versions of each package to keep when cleaning the packages cache:
KeepNumPackages = 3

## Remove only the versions of uninstalled packages when cleaning the packages cache:
#OnlyRmUninstalled

## Download updates in background:
#DownloadUpdates

## Maximum Parallel Downloads:
MaxParallelDownloads = 4

#CheckFlatpakUpdates

#EnableSnap

#EnableFlatpak

Enfim, na sétima aba, me chocou a configuração-padrão do Pamac de manter 3 versões de cada pacote, para o caso de precisar fazer downgrade. — Na verdade, parece ser um padrão do Arch / pacman (embora eu ainda não tenha encontrado em qual arquivo de configuração está). Há várias dicas minuciosas aqui e aqui. — Acabei com a impressão (a confirmar) de que esse recurso do pamac talvez seja um facilitador para limpeza regular automática.

Na minha experiência, nenhuma dessas alternativas apresenta tanto resultado quanto o velho e bom # pacman -Sc, que num piscar de olhos esvazia 1 GiB (ou mais, dependendo dos pacotes acumulados), deixando apenas a versão instalada de cada pacote. — A verdade é que, em 4 anos, nunca senti necessidade de fazer downgrade de pacotes — a menos que o próprio pacman tenha cuidado disso, sem que eu prestasse muita atenção.

Portanto, vou usando tudo isso como um guia, — mas tentando identificar onde está cada opção, nos arquivos de configuração e nos parâmetros dos comandos. — Em suma, tento distinguir o que é do Arch e do pacman, e o que é do pamac e do Manjaro.

# date; pacman -Syyu; date
Mon 31 May 15:39:16 -03 2021
:: Synchronising package databases...
 core                                                 165.3 KiB  1462 KiB/s 00:00
 extra                                               1913.2 KiB  7.30 MiB/s 00:00
 community                                              6.5 MiB  17.2 MiB/s 00:00
 multilib                                             178.1 KiB  1619 KiB/s 00:00
:: Starting full system upgrade...
 there is nothing to do
Mon 31 May 15:39:19 -03 2021

$ date; pamac update --force-refresh; date
Mon 31 May 15:53:25 -03 2021
Preparing...
Synchronizing package databases...
Refreshing core.db...
Refreshing extra.db...
Refreshing community.db...
Refreshing multilib.db...
Refreshing core.files...
Refreshing extra.files...
Refreshing community.files...
Refreshing multilib.files...
Nothing to do.
Transaction successfully finished.
Mon 31 May 15:53:45 -03 2021

Para isso, procuro sempre atualizar, primeiro, tudo que é coberto pelo pacman -Syyu, e só depois, o pamac update. — É um pouco mais trabalhoso, mas nada que o aprendizado não pague com juros. — Fazer isso 1 vez por semana é até uma brincadeira agradável.

O resultado desse caminho pessoal pode ser resumido de um modo bem simples:

  2021-05-18   09:45   # pacman -Syyu
  2021-05-18   09:50   $ pamac update --force-refresh

  2021-05-23   11:51   # pacman -Syyu
  2021-05-23   11:58   $ pamac update --force-refresh

  2021-05-26   19:06   # pacman -Syyu
  2021-05-26   19:06   $ pamac update --force-refresh

  2021-05-31   15:26   # pacman -Syyu
  2021-05-31   15:26   # pamac update --force-refresh

  2021-05-31   15:51   # pamac update --force-refresh
  2021-05-31   15:53   $ pamac update --force-refresh

  2021-06-02   10:36   # pacman -Syyu
  2021-06-02   10:37   $ pamac update --force-refresh

  2021-06-05   12:41   # pacman -Syyu
  2021-06-05   12:43   $ pamac update --force-refresh

  2021-06-06   08:51   # pacman -Syyu
  2021-06-06   08:51   $ pamac update --force-refresh

  2021-06-13   10:24   # pacman -Syyu
  2021-06-13   10:30   $ pamac update --force-refresh

Ainda estou me acostumando a sempre sair do su, para usar o pamac — pois no início me descuidei muitas vezes:

# history | grep 'pacman -S \|pamac install'
...
   45  2021-04-27   11:43    pacman -S foliate
   76  2021-04-30   09:26    pacman -S python-html2text
   77  2021-04-30   09:46    pacman -S --needed base-devel
   87  2021-04-30   12:08    pacman -S mc
  166  2021-05-10   10:23    pamac install aha
  174  2021-05-10   12:52    pamac install google-earth-pro
  175  2021-05-12   05:12    pacman -S smplayer
  205  2021-05-13   18:46    pamac install google-chrome
  213  2021-05-16   19:21    pacman -S gparted

Após esse aprendizado, instalei o pamac no Arch, — ativei o AUR e suas atualizações — e descobri que ele também detecta e atualiza os pacotes do AUR que eu tinha instalado manualmente.

Bônus - Repositório “Manjariando”

xxx

Experiências anteriores (2017-2018)

Manjaro KDE 16.10.3 stable, em 2 Jan. 2017

Manjaro foi minha primeira distro “não-debian”, em 1º Janeiro 2017, como forma de iniciar uma aproximação ao Arch — cuja Wiki já me vinha sendo muito útil, pelas informações claras e bem estruturadas, a partir de pesquisas no Google sobre cada problema que precisei resolver (no Kubuntu, Debian, Mint, KDE Neon), nos anos anteriores.

Aquela experiência me deixou ótimas lembranças. Em poucos meses, no início de 2017, quebrei o Manjaro umas 3 ou 4 vezes, pelo menos — e todas as vezes, o conserto foi muito simples e rápido, bastando uma busca no Google pelas palavras-chave mais relevantes em cada caso.

Jan. 2017 - Instalação do Manjaro KDE 16.10.3 stable
Jan. 2017 - Consertando o Manjaro após erro em atualização
Mar. 2017 - Transição do Manjaro (rolling-release) para 17.0

Meu único motivo para removê-lo, é que logo depois descobri o Revenge Installer (agora chamado Zen Installer), instalei o Arch, gostei — mas meu “Menu de inicialização”, controlado pelo Mageia, exigia “edição manual” do /boot/grub/grub.cfg para conseguir carregar o Arch e o Manjaro, após cada atualização do Grub. — Usando o editor interno do Midnight Commander (mcedit) como root, era muito fácil fazer 1 correção com uma busca-e-troca global (que o editor lembra e repete num instante), mas era impraticável fazer 2 buscas-e-trocas manuais, uma para o Arch e outra para o Manjaro, a cada atualização do Grub.

Ok, o Grub do Arch ou do Manjaro podia gerar as entradas corretas para ambos — mas não para o openSUSE, mesmo depois que instalei neles alguns pacotes para lidarem com BtrFS. — Como eu ainda estava aprendendo a lidar com o Grub e com distros “não-debian”, optei por manter apenas o Arch.

Também pesou naquela decisão o fato de o Manjaro parecer uma “repetição” do Arch. — Eu queria explorar as distros mais “distantes” umas das outras — e preferi investir no “original”, que depois consegui instalar “na unha”, e continuo usando há 4 anos.

Uma segunda tentativa, em 2018, esbarrou em alguns problemas — cooler entupido de sujeira e Grub ensandecido:

Abr. 2018 - Manjaro - live, install, config (II)

Escolhendo Grub entre vários Linux

Grub enlouquecido com 12 distros Linux

Limpeza do Cooler da CPU

xxxx

— … ≠ • ≠ … —

PC desktop UEFI / GPT

Slackware 15.0 KDE

noreply@blogger.com (Mboaba) — Tue, 23 Feb 2021 00:56:00 +0000

Slackware 15.0

Isto não é um "tutorial". — Estou muito longe de aprender o básico sobre o Slackware. — Isto é apenas um levantamento do que fiz (inclusive erros), para não esquecer.

Fico feliz, se for de alguma utilidade para outros usuários iniciantes no Slackware — mas quero deixar bem claro que nada disso deve ser tomado como "o correto".

Índice

Instalei o Slackware 15.0 a partir de uma sessão Live, e não encontrei a opção de escolher ou excluir grupos de pacotes — portanto, foram instalados todos os pacotes da ISO Live — e é isso que eu relato em primeiro lugar.

Slackware 15.0 (Live, 2022)
Slackware "alpha1" ou 14.2+ (Installer, 2021)
Slackware 14.2 by AlienBob (Live, 2018)
Slackware 14.2 by AlienBob (Live, 2017)

Cerca de um ano atrás, instalei o que foi jocosamente apelidado "alpha1" — na verdade, o "14.2+" (current) daquele momento. — Esse outro relato está no final (adiante).

Nos 2 links, estão relatos de outras instalações, em anos anteriores — com várias anotações que (ainda) não incluí aqui — porque não mudaram, ou porque não aprendi coisas novas sobre elas.

O presente relato foca mais no que estou aprendendo agora.

Slackware 15.0 (Live, 2022)

Algumas opções de imagens ISO do Slackware 15.0

Baixei do site da Holanda a imagem slackware64-live-15.0.iso — pela comodidade de fazer a instalação a partir de uma sessão Live — e só depois percebi que eu teria mais opções se usasse a imagem slackware64-15.0-install-dvd.iso.

Verificação da ISO e queima em DVD

Verifiquei a integridade do arquivo pelo md5sum e queimei pelo K3b em DVD, para guardar.

Cópia de uma partição /home com minha configurações

Decidi instalar o Slackware 15.0 no "slot" Linux8 + Home8, que estava desocupado.

Sim, tenho "slots" para até 12 distros em dualboot.

Primeiro, copiei para Home8 a partição /home de uma instalação anterior do Slackware, com minhas configurações pessoais (sempre KDE).

Alteração do rótulo e do UUID da partição copiada

Apliquei na cópia o rótulo (Label) Home8 e alterei seu identificador UUID, para diferenciá-la do original copiado.

Menu de Boot da sessão Live do Slackware 15.0

Antes de iniciar a sessão Live do Slackware 15.0, selecionei Teclado Português do Brasil (pt_BR), Idioma Inglês do Reino Unido (en_UK) e Fuso horário de São Paulo / América (BRT).

Examinei os parâmetros da linha de comando pelo recurso "E" (editar) do Grub, mas ali todas as opções remetem a um mesmo conjunto de variáveis "$sl", o que pouco esclarece.

A sessão Live carregou com Inglês britânico e Teclado ABNT2, mas ainda precisei ativar a sincronização NTP para finalmente exibir o horário BRT.

Instalador + htop + Sensors, para monitorar a instalação

Fiz algumas configurações no Spectacle, notificações (som em vez de visual), teclas de atalho, Dolphin, Gwenview, tema (Breeze Dark), estilo (Maia Transparent), decoração de janelas (Transparent Oxygen), Menu (em cascata), gerenciador de tarefas, sensores (sensors-detect) etc., para facilitar a documentação visual da instalação.

Ocultei da tela o ícone do Instalador (Setup2hd), mas ele ainda podia ser encontrado na pasta Desktop. — Para monitorar o processo de instalação, executei htop e watch-sensors em janelas menores do Konsole.

O Instalador detectou que já havia partições "tipo Linux" e ofereceu a possibilidade de alterar o esquema de particionamento, mas como eu já tinha tudo pronto, pulei essa etapa.

Menu com as etapas do Instalador do Slackware

Pulei também a etapa de adicionar uma partição Swap, pois o Instalador do Slackware costuma alterar seu identificador UUID — o que me obrigaria a fazer essa alteração, depois, nas outras 10 distros instaladas, já que todas usam a mesma partição Swap.

Seleção das partições para instalação do Slackware 15.0

Selecionei a partição-raiz e optei por não formatá-la. — Selecionei uma segunda partição, de novo "não-formatar", e montar como /home.

Concluindo a seleção das partições de destino (target)

De volta à seleção de partições, escolhi "Continuar" — e o Instalador do Slackware apresentou um resumo do que seria adicionado ao arquivo /etc/fstab (até esse momento).

Partição EFI e outras partições FAT / NTFS

O Instalador do Slackware detectou a partição EFI automaticamente e só permitiu aceitar incluí-la no /etc/fstab.

Ainda detectou outras partições FAT ou NTFS que supôs serem do Windows e perguntou se eu queria incluí-las no arquivo /etc/fstab para serem montadas automaticamente. — Trata-se do Pendrive onde eu estava gravando as capturas de tela, e rejeitei a proposta.

Instalação dos pacotes do Slackware, do DVD para o SSD interno

O Instalador da sessão Live ofereceu as alternativas de baixar os pacotes de uma rede NFS, de um servidor FTP / HTTP, de um compartilhamento Samba, ou do próprio DVD. — Uma vez escolhido "DVD", os pacotes puderam ser instalados rapidamente, sem mais perguntas (e sem direito a escolhas).

(A escolha dos pacotes a serem instalados — Package series selection — só é oferecida pelo Instalador tradicional, sem sessão Live).

Criação do Usuário do Slackware e definição da senha root

Depois de instalados os pacotes do Slackware 15.0, criei o Usuário, defini a senha root — e foi gerado o initrd.gz.

Uma mensagem indica que a instalação incluiu as opções de Teclado e Idioma da sessão Live, mas não faz referência ao Fuso horário.

Em seguida, foram executados o mkfontdir, mkfontscale e o fontconfig update.

Firewall e interface de Rede na instalação do Slackware 15.0

A configuração do Firewall ofereceu a possibilidade de expor algumas portas TCP / UDP a serem escolhidas — o que poderia facilitar minha vida com o KDE Connect — mas naquele momento eu não tinha ideia disso.

Aceitei a escolha da interface de Rede eth0 e segui adiante.

Opções de bootloader no instalador do Live Slackware 15.0: Lilo e eLilo

Aceitei o padrão de não instalar o Lilo — mas também não me interessava o eLilo. — Pelas experiências anteriores, eu sabia que Grub estava incluído na instalação, e bastaria atualizá-lo (gerar o arquivo /boot/grub/grub.cfg) manualmente, mais tarde, para o Grub do openSUSE detectar corretamente o Slackware 15.0.

Escolhas ao configurar Rede no Slackware

Defini o HostName, DomainName, aceitei as propostas de dispensar VLAN e de escolher NetworkManager.

Ativação do serviço NTP e escolha do Fuso horário

Incluí a sincronização horária (NTP) entre os serviços a serem iniciados com o boot. — Alterei o relógio do hardware para UTC e selecionei o Fuso horário local (Timezone) BRT.

Por fim, o Instalador do Slackware solicitou a escolha do editor-padrão, entre Elvis, Nvi ou Vim — e concluiu a instalação do Slackware 15.0 a partir da sessão Live.

Atualização do Grub após a instalação do Slackware 15.0

Atualizei o Grub do openSUSE, para detectar e incluir o Slackware 15.0.

Naquele momento, eu ainda tinha outra instalação do Slackware 14.2+ (current), feita 1 ano antes, em outra partição — que nesse dia ainda apareceu no Grub.

Aproveitei para documentar em TXT o novo quadro das partições existentes, pelos comandos lsblk e blkid.

Correção inicial do Grub para carregar o Slackware depois de instalado

Para carregar o Slackware pela primeira vez após a instalação, corrigi o Grub do openSUSE, substituindo o parâmetro generic por huge — e em seguida teclei CTRL+X para prosseguir com o boot e chegar à tela de Login.

No detalhe (acima), as opções de sessão Plasma X11, Wayland, Full Wayland, Failsafe, Xfce, Default, oferecidas na tela de Login.

Efeitos da configuração herdada via partição /home

Devido às configurações herdadas via partição /home, o Slackware tenta montar outras partições existentes no computador — mas neste momento, isso exigiria a senha de root — o que não me interessava, pois o Usuário não teria direitos de escrita. Portanto, cancelei.

Pelo nano, criei o arquivo que permitiria a montagem automática de todas as demais partições (que não têm ligação com o Slackware):

# nano /etc/polkit-1/rules.d/99-udisks2.rules

// 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; } });

Com isso, passam a funcionar as configurações de montagem automática (udisks2) definidas em KDE System settings > Removable storage > Removable devices — herdadas via /home:

Enable automatic mounting of removable media

Automatically mount all removable media at login
Automatically mount all removable media when attached

Só depois, lembrei de configurar o bash para datar o histórico dos comandos:

$ history
  ...
  372  2022-02-05_16-21-24 echo 'export HISTTIMEFORMAT="%F_%H-%M-%S "' >> ~/.bashrc
  373  2022-02-05_16-21-29 history

# history
    1  2022-02-05_16-21-37 mc
    2  2022-02-05_16-21-37 nano /etc/udev/rules.d/99-udisks2.rules
    3  2022-02-05_16-21-37 nano /etc/polkit-1/rules.d/99-udisks2.rules
  ...
    7  2022-02-05_16-21-37 echo 'export HISTTIMEFORMAT="%F_%H-%M-%S "' >> ~/.bashrc
    8  2022-02-05_16-21-39 history

O papel de parede, o ícone do Slackware no Menu — tudo já "veio pronto". — Entre os lançadores junto ao Menu, faltava o ícone do Chromium, que eu ainda teria de instalar.

Configuração do Login automático no Slackware

Também tratei de configurar o Login automático do Usuário na sessão Plasma (X11).

Instalação do Chromium a partir de um pacote recente

Fiz a atualização inicial do slackpkg — # slackpkg update — mas ele não encontrou o Chromium.

Instalei o Chromium a partir de um pacote do Slackware-AlienBob-Slackbuilds-current — sem parar para verificar se isso estava "certo" ou "errado". — Infelizmente, o Google não aceitou sincronizar, e mais tarde substituí pelo Google-Chrome (adiante).

Desabilitando Os_Prober e gerando o arquivo grub.cfg

Editei o arquivo /etc/default/grub — adicionei uma linha:

GRUB_DISABLE_OS_PROBER=true

para que não perca tempo detectando outras distros (deixo isso para o openSUSE) — e gerei o arquivo grub.cfg pelo comando # grub-mkconfig -o /boot/grub/grub.cfg.

A partir desse momento, o Grub do openSUSE já pode detectar o parâmetro correto — huge, em vez de generic — para carregar o Slackware.

Retirando o HPLIP do Painel

Como não tenho impressora, desativei a exibição do widget HPLIP do Painel. — Em outras épocas, cheguei a remover o pacote. — Talvez ainda faça isso, mais tarde.

Instalando fontes TTF

Copiei para /usr/share/fonts/TTF algumas fontes True Type — e executei o comando fc-cache -fv para serem detectadas. — Fechei e reabri o Chromium, para incorporar as novas fontes instaladas.

Instalação do Conky e ajuste das configurações

Instalei pelo comando installpkg um pacote antigo do Conky — também sem verificar se isto é "certo" ou "errado". — Funcionou, e fiz alguns ajustes em suas configurações.

Era um pacote (conky-1.10.8-x86_64-1_SBo.tgz) que eu tinha encontrado já completo, com as dependências. — Dias depois, aprendi a fazer do modo "correto", e substituí pelo pacote atualizado do Conky (ver adiante).

Lembrei que ainda não tinha executado o comando # sensors-detect — para detectar e configurar os sensores existentes — e tratei disso em seguida.

Instalação do yt-dlp pelo pip

Tentei instalar várias coisas por comandos pip — sem sucesso, até agora, com exceção do yt-dlp — mas demorei mais de um mês para prestar atenção ao aviso de que precisava colocar ~/.local/bin no PATH.

Em todo caso, as novas tentativas de instalação serviram para atualizar o pacote:

2022-02-14  10:05  $ python3 -m pip install -U yt-dlp
...
2022-03-23  18:19  $ python3 -m pip install -U yt-dlp
2022-03-23  18:23  $ echo "export PATH=\"/home/flavio/.local/bin:\$PATH\"" >> ~/.bashrc && source ~/.bashrc
...
2022-03-27  10:53  $ yt-dlp https://www.youtube.com/watch?v=XYXYXYXYXYX

Instalação do Google-Chrome no Slackware 15.0

Como não encontrei o Google-Chrome no Slackpkg, procurei no PKGs — que indicou o download de um pacote "current/extra" do Slackel. — Isto representou um certo downgrade (de 98 para 97), mas funcionou e pude sincronizar minha conta Google.

Semanas depois, o Google-Chrome apresentou um aviso de "Update" no canto superior direito. — Refiz o caminho e atualizei para a versão 99 — novamente, do "current/extra" do Slackel; e aproveitei para remover o Chromium:

# history | grep 'chrom\|Chrom'
   12  2022-02-05_16-32-07 slackpkg search chromium
   14  2022-02-05_16-37-23 slackpkg file-search chromium
   17  2022-02-05_17-11-27 installpkg chromium-98.0.4758.80-x86_64-1alien.txz
   42  2022-02-14_10-27-48 cd /home/flavio/Packages/Google-Chrome-by-Slackel/
   43  2022-02-14_10-28-21 upgradepkg --install-new google-chrome-97.0.4692.71-x86_64-1dj.txz
   85  2022-03-23_13-53-00 upgradepkg google-chrome-99.0.4844.51-x86_64-1dj.txz
   96  2022-03-23_18-15-51 slackpkg remove chromium

Deletando a antiga instalação do Slackware 14.2+

6 Março 2022 - Pelo GParted, desmontei e formatei as partições Linux11 e Home11, onde estava a antiga instalação do Slackware 14.2+ (current), que cumpria o papel de "15 alpha1".

Configurando o crontab e corrigindo o script

Configurei o crontab para executar um script 10 minutos após o início da sessão — e corrigi o script, que era da instalação anterior (Linux11).

Edição do arquivo fstab e ativação do Swap

19 Março 2022 - Finalmente lembrei de incluir a partição Swap no arquivo /etc/fstab do Slackware 15.0 — apenas copiando essa linha do backup mais recente da instalação anterior — e ativei pelo comando # swapon --all.

Já faz algum tempo que uso /dev/LABEL no fstab do Slackware, e até o momento não tive motivo para queixa.

Remoção do Xfce do Slackware 15.0

22 Março 2022 - A remoção do Xfce foi simples e rápida. — Executei o comando # slackpkg remove xfce e ele abriu um menu para escolha dos pacotes. — Deixei todos marcados e mandei prosseguir.

 # history
   ...
   47  2022-03-22_07-14-52 slackpkg remove xfce
   48  2022-03-22_07-16-13 slackpkg remove y
   ...
   55  2022-03-22_08-29-54 slackpkg remove freecell-solver kigo knights kteatime libkdegames libkmahjongg palapeli kpat
   56  2022-03-22_08-32-11 slackpkg remove kcontacts korganizer kmail knotes kjots kalarm

Repeti o processo para o conjunto "Y" (jogos BSD) — mas para os jogos do KDE tive de compor um comando item por item, a partir de uma busca por "games" na lista de pacotes instalados — e a mesma coisa para meia-dúzia de pacotes do PIM (Personal Information Management), que não uso.

Com os primeiros 2 comandos, foram removidos 32 pacotes, reduzindo o total instalado de 1600 para 1568 — número que o Conky só atualizou após reiniciar o Slackware. — Após os outros 2 comandos e nova reinicialização, o número de pacotes instalados caiu para 1553.

Ainda preparei uma lista de 9 pacotes Akonadi, mas não prossegui. — A verdade é que não sei se o Xfce foi totalmente removido, nem quantos pacotes órfãos ficaram, até este momento.

Atualização do Google-Chrome no Slackware 15.0

23 Mar. 2022 - O Google-Chrome apresentou um aviso de nova versão. — Fui ao site pkgs.org, de onde eu tinha baixado o pacote ao instalar, e baixei a nova versão.

Dessa vez, usei o comando upgradepkg, sem qualquer parâmetro:

# cd Packages

# upgradepkg google-chrome-99.0.4844.51-x86_64-1dj.txz

+==============================================================================
| Upgrading google-chrome-97.0.4692.71-x86_64-1dj package using ./google-chrome-99.0.4844.51-x86_64-1dj.txz
+==============================================================================
Pre-installing package google-chrome-99.0.4844.51-x86_64-1dj...
Removing package: google-chrome-97.0.4692.71-x86_64-1dj-upgraded-2022-03-23,13:53:00
  --> Deleting /usr/doc/google-chrome-97.0.4692.71/latest-chrome.sh
  --> Deleting empty directory /usr/doc/google-chrome-97.0.4692.71/
Verifying package google-chrome-99.0.4844.51-x86_64-1dj.txz.
Installing package google-chrome-99.0.4844.51-x86_64-1dj.txz:
(...)
Executing install script for google-chrome-99.0.4844.51-x86_64-1dj.txz.
Package google-chrome-99.0.4844.51-x86_64-1dj.txz installed.
Package google-chrome-97.0.4692.71-x86_64-1dj upgraded with new package ./google-chrome-99.0.4844.51-x86_64-1dj.txz.

Corrigindo o Hostname na configuração do KDE Connect

Embora o Hostname da nova instalação seja "Linux8", o KDE Connect insistia em identificá-la como "Linux11" — já que copiei a partição /home de outra instalação anterior do Slackware.

Pelo Midnight-Commander (mc), editei o arquivo ~/.config/kdeconnect/config para corrigir isso. — Só funcionou depois de reiniciar o Slackware. — Ainda preciso aprender a atualizar coisas como essas, sem recorrer a um Logout / Login ou a um novo boot.

Habilitando portas para o KDE Connect

25 Março 2022 - De início, porém, o celular não encontrava o computador e vice-versa. — Uma das soluções que encontrei era executar 2 comandos iptables a cada nova sessão do Slackware — mas a seção Firewall do KDE System Settings exigia instalar o UFW ou o firewalld, quando eu tentava tornar essa configuração permanente.

Por fim, encontrei o comando myfwconf, que permitiu refazer a configuração oferecida durante a instalação do Slackware. — Desta vez, escolhi "Não", quando ofereceu bloquear todas as conexões vindas de fora. — Pulei a primeira lista de portas a serem deixadas abertas (nenhuma); e na etapa seguinte especifiquei as faixas de portas TCP / UDP a serem aceitas:

# history 10
  105  2022-03-23_20-05-12 iptables -I INPUT -p tcp --dport 1714:1764 -j ACCEPT
  106  2022-03-23_20-05-20 iptables -I INPUT -p udp --dport 1714:1764 -j ACCEPT
  ...
  112  2022-03-25_09-00-29 myfwconf

Encontrei outras "receitas" — por exemplo, usando sshfs — mas minha absoluta ignorância nesses assuntos não me permite avaliar (e muito menos, recomendar) o que seria mais seguro ou menos seguro.

Notei que não tive mais de "autorizar" o emparelhamento solicitado pelo celular — como nos dias anteriores (e também nas outras distros) — e receio que isso possa ser uma falha de segurança (a menos que volte a pedir, pois em outras distros não pede todos os dias).

Início da instalação de vários pacotes SlackBuilds para Slackware 15.0

Resolvi focar no SlackBuilds — que oferece vários pacotes de que eu precisava, e específicos para Slackware 15.0 — pois misturar várias fontes e procedimentos estava me proporcionando mais confusão do que resultados.

Para facilitar, anotei os "primeiros passos":

1) Baixar o pacote SlackBuild (.tar.gz) e descompactar. — Ele cria uma pasta com seus arquivos

2) Dentro da pasta, tornar o script "packageName.SlackBuild" executável (chmod ou Dolphin)

3) Baixar o pacote original do link fornecido em "packageName.INFO", para dentro da mesma pasta (wget ou browser)

3.1) Baixar e instalar as dependências indicadas em "packageName.INFO"

4) Entrar na pasta e executar o script: # ./packageName.SlackBuild —Se tudo correr bem, termina com uma mensagem "Slackware package /tmp/packageName_SBo.tgz created".

5) Instalar ou reinstalar, conforme o caso:

5.1) # upgradepkg --install-new /tmp/packageName_SBo.tgz (instalar)

5.2) # upgradepkg --install-new --reinstall /tmp/packageName_SBo.tgz (atualizar)

5.3) # upgradepkg /tmp/packageName_SBo.tgz (atualizar???)

Naturalmente, era um guia estritamente "prático" — sem "distrações". — Recomendo ler com atenção o guia oficial do SlackBuilds.

Ainda não testei o sub-item 5.3, por exemplo — exceto ao atualizar o Google-Chrome (acima), mas não se tratava de um SlackBuilds. — Faz sentido, mas não sei se explode.

# history

  119  2022-03-25_20-09-38 wget https://github.com/theZiz/aha/archive/0.5.1/aha-0.5.1.tar.gz
  120  2022-03-25_20-13-14 ./aha.SlackBuild
  121  2022-03-25_20-18-33 upgradepkg --install-new /tmp/aha-0.5.1-x86_64-1_SBo.tgz

  147  2022-03-25_21-09-14 chmod +x html2text.SlackBuild
  148  2022-03-25_21-09-35 ./html2text.SlackBuild
  151  2022-03-25_21-15-01 upgradepkg --install-new /tmp/html2text-2020.1.16-x86_64-1_SBo.tgz

  156  2022-03-25_21-38-45 chmod +x screenfetch.SlackBuild
  157  2022-03-25_21-39-25 ./screenfetch.SlackBuild
  159  2022-03-25_21-40-32 upgradepkg --install-new /tmp/screenfetch-3.9.1-noarch-1_SBo.tgz

  162  2022-03-25_22-03-05 chmod +x speedtest-cli.SlackBuild
  163  2022-03-25_22-03-25 ./speedtest-cli.SlackBuild
  165  2022-03-25_22-05-35 upgradepkg --install-new --reinstall /tmp/speedtest-cli-2.1.3-x86_64-3_SBo.tgz

  184  2022-03-26_14-09-41 chmod +x LibreOffice.SlackBuild
  185  2022-03-26_14-10-59 ./LibreOffice.SlackBuild
  ...
  190  2022-03-26_14-54-46 JAVA=no sh LibreOffice.SlackBuild
  191  2022-03-26_15-06-06 JAVA=no PARALLEL=1 sh LibreOffice.SlackBuild
  195  2022-03-26_20-29-37 upgradepkg --install-new /tmp/LibreOffice-7.3.1.3-x86_64-1_SBo.tgz

  199  2022-03-27_11-22-46 ./imlib2.SlackBuild
  201  2022-03-27_11-23-42 upgradepkg --install-new /tmp/imlib2-1.7.4-x86_64-1_SBo.tgz

  204  2022-03-27_11-29-41 ./lua53.SlackBuild
  206  2022-03-27_11-31-14 upgradepkg --install-new --reinstall /tmp/lua53-5.3.4-x86_64-1_SBo.tgz

  211  2022-03-27_11-35-19 ./conky.SlackBuild
  213  2022-03-27_11-37-43 upgradepkg --install-new --reinstall /tmp/conky-1.12.2-x86_64-1_SBo.tgz

O histórico dos comandos (acima) mostra que fiz bem em começar pelos pacotes mais simples e menores — e deixar o Conky e o LibreOffice para o final. — Consegui instalar o Conky (após suas dependências imlib2 e lua53), mas o LibreOffice me ocupou quase um dia inteiro, e ainda "aborta" logo que começa a abrir.

Bloqueando instalação / atualização / remoção de pacotes pelo slackpkg

Àquela altura, percebi a utilidade do comando # slackpkg clean-system para eliminar rapidamente vários pacotes não-oficiais que não deram certo, para tentar de novo — e mais ainda, a utilidade de colocar em /etc/slackpkg/blacklist os pacotes não-oficiais que não quero que sejam removidos — bem como os pacotes oficiais que eu não quero que voltem a ser instalados.

\\\\

Slackware "alpha1" KDE (Installer, 2021)

Slackware 15 alpha1

• “Slackware 15 alpha1” é apenas um apelido informal para as versões mais recentes do Slackware 14.2 -Current — que diferem bastante do Slackware 14.2 (stable), cujas imagens ISO mantêm a data de seu lançamento (01-Jul-2016). — A documentação é clara:

Slackware -Current é o branch de desenvolvimento do Slackware que eventualmente é lançado como uma versão estável quando considerado pronto (e então dividido novamente, como o branch de desenvolvimento para a próxima versão). É semelhante em função ao ramo de teste de outras distribuições e as mesmas ressalvas se aplicam a -Current.

Desde o lançamento da última versão estável, o ramo -Current acumulou 45 “changelogs” em 2016; mais 140 em 2017; outros 238 em 2018; mais 325 em 2019; outros 320 em 2020; e 44 nos primeiros 54 dias de 2021.

No “changelog” de 15 Fev. 2021, falou-se em “Slackware 15 alpha1”, sem link para nenhuma imagem ISO. — Nenhum “lançamento” oficial. — No máximo, uma cutucada :-) nos fãs que há anos cobram uma versão estável atualizada.

No dia seguinte, Distrowatch anunciou a boa nova, com 2 links diferentes para download direto da imagem ISO “Installer” do Slackware 14.2 -Current — um na própria notícia; e outro na coluna “Latest Distributions” — a partir de espelhos no Reino Unido e na Holanda.

Índice

Download
Instalação
Configurações

Download

Download da imagem ISO do Slackware 15 alpha1

Na falta de um torrent (que o Distrowatch não publicou nos 7 dias seguinte), foi bom ter pelo menos 2 links para escolher — pois às vezes enfrento baixíssima velocidade em downloads da Holanda; e outras vezes, em downloads do Reino Unido:

https://slackware.uk/people/alien-current-iso/slackware64-current-iso/slackware64-current-install-dvd.iso
https://slackware.uk/people/alien-current-iso/slackware64-current-iso/MD5SUM

https://slackware.nl/slackware/slackware64-current-iso/slackware64-current-install-dvd.iso

Rastreando os links até a origem, verifiquei que, afora o “DVD Instalador”, a única outra opção era o “Mini-Instalador” — que exigiria download durante a instalação, com risco de baixa velocidade desde um espelho ou desde o outro, pois a rota entre Europa e Brasil passa pelos Estados Unidos, sujeito a fortes variações de prioridade. — Ver (CTRL+F) “Mapa global”, em Teste de velocidade.

Verifiquei a imagem ISO pela soma MD5 e queimei pelo K3b em DVD, para guardar.

Live Slackware “15 alpha1” by AlienBob

Parecia haver uma possível terceira opção — as imagens Live ISO 14.2 -Current by AlienBob, também atualizadas em 15 Fev. 2021 — mas eu não podia ter certeza, sem examinar mil informações abstrusas no changelog.

Instalei uma, rodei a outra em sessão Live, e comparei em um nível bem superficial. — A julgar só pelas informações do KInfocentre, a “única” diferença estaria na revisão do Kernel — 5.10.15 vs. 5.10.16 — mas não examinei outros milhares de pacotes, para poder afirmar qualquer coisa além disso.

Instalação

Teclado e Login no Instalador do Slackware

Ao iniciar o DVD “Instalador”, ele oferece a opção de carregar um Teclado “Não-US”, e em seguida deve-se logar como root (não pede senha).

Antes e depois do login, apresenta orientações para upgrade de uma instalação preexistente, ferramentas para formatar partições etc. — Pulei tudo isso, pois eu iria fazer uma nova instalação, e as partições já estavam prontas.

Menu do instador do Slackware

O menu do Instalador apresenta os passos a serem seguidos, em sequência, e por experiência anterior eu já sabia que em várias dessas etapas não existe a opção de voltar atrás, nem de voltar ao menu, que só volta a ser apresentado no final. — Por isso, tive o cuidado de começar pelo primeiro item da lista.

Na dúvida sobre eventuais efeitos na “regionalização” (locale), escolhi (de novo) “UK”, pois não uso acentuação nos consoles virtuais (tty2, tty3). — Há várias coisas no Slackware que ainda não entendo bem.

Por distração, aceitei configurar a partição Swap detectada. — Eu devia lembrar que o Instalador do Slackware formata e altera o identificador UUID da partição. — O mais recomendável era não configurar Swap pelo Instalador (desmarcar a partição detectada), pois é muito fácil configurá-lo mais tarde, manualmente.

Bastou clicar “Ok”, e o antigo UUID foi perdido, no mesmo instante.

Por causa disso, depois tive de corrigir o /etc/fstab e o /etc/default/grub das outras distros, com o novo identificador UUID.

Note que “Add Swap” é um passo separado de “Target”, — para escolha das demais partições, — que vem a seguir.

Partição-raiz e /home no Instalador do Slackware

Para configurar a partição-raiz, basta selecioná-la. — Para configurar outras partições, é necessário indicar manualmente o ponto de montagem de cada uma. — Nos dois casos, optei por não formatar, pois já estavam formatadas (e vazias).

Após cada escolha, nessa etapa, o Instalador oferece a possibilidade de configurar outra partição — e mostra um quadro das partições (só até sda12, sdb12), onde se podem conferir as escolhas já feitas (e alterar, ou fazer outras). — Clicar em “Continue” para concluir e e aplicar.

Partição EFI encontrada pelo Instalador do Slackware

Ainda nesse passo, o Instalador identifica a partição EFI existente e propõe configurar como /boot/efi.

Escolha de software no Instalador do Slackware

No passo seguinte, o Instalador do Slackware oferece a escolha da fonte de software, e de quais softwares serão instalados a partir dela.

Naquele momento, eu poderia ter desmarcado o Xfce, ou o KDE (ou ambos), mas prestei mais atenção no resto da lista, e não pensei nisso.

Seleção de pacotes do Slackware

O Instalador do Slackware ainda oferece a possibilidade de escolher outros softwares (por tarefas), mas optei pelo mais rápido (e seguro), que é aceitar todos.

Em seguida, gera RamDisk inicial do Kernel e atualiza a lista de fontes de letras. — Descartei a oferta de gerar um Pendrive de Boot. — Também descartei instalar o carregador de boot Elilo (para UEFI). — Aceitei instalar o GPM, que permite usar o Mouse para cortar e colar texto nos consoles virtuais.

O Grub do openSUSE e do Mageia detecta e permite carregar o Slackware, desde que você entre no modo de Edição do Grub e substitua “generic” por “huge”. — Então, basta gerar o Grub do próprio Slackware, e depois disso o Grub do openSUSE e do Mageia detecta e incorpora esse parâmetro.

Configuração de rede do Slackware

Na configuração de rede, adotei o hostname “Linux11”, inventei um domínio fictício apenas por ser requisito para prosseguir, aceitei a opção de usar o NetworkManager, e confirmei.

Seleção de serviços no Instalador do Slackware

Entre os serviços a serem iniciados automaticamente, me limitei a acrescentar o NTPD — pois não tenho certeza de que o KDE faria isso. — Já enfrentei alguma dificuldade com isso, em instalações anteriores do Slackware, por motivos que ainda não consegui entender.

Relógio do sistema e fuso horário

Alterei a opção de Relógio do hardware para UTC; e selecionei o Fuso horário do Centro-Sul do Brasil (BRT = UTC-0300).

Escolha do Gerenciador de janelas no Slackware

Aceitei a proposta de usar o Gerenciador de janelas do KDE — que afinal, é a interface que pretendo usar. — Ignoro se foi instalado Fluxbox ou qualquer das outras opções oferecidas, exceto Xfce.

De volta ao Menu do Instalador do Slackware, no final

O Instalador do Slackware ainda solicitou criar a senha de Root e, ao encerrar o processo, voltou ao Menu. — Não me sinto seguro das consequências, caso entre em algum dos passos e tente alterar alguma coisa. — Afinal, a instalação já foi feita.

Restava escolher Exit para reiniciar — ou voltar à tela de comandos.

O mais prático seria voltar à tela de comandos, para criar o usuário e gerar o arquivo /boot/grub/grub.cfg — mas esqueci, e apenas reiniciei.

Exame do Slackware a partir de outra distro

Pelo openSUSE, confirmei que a /home do Slackware ainda estava vazia, pois o Instalador não cria conta de usuário. — Eu poderia ter feito isso por comando, antes de reiniciar. Como não lembrei na hora, vou ter de fazer agora.

Também confirmei que o Grub estava instalado, embora sem o arquivo /boot/grub/grub.cfg — que eu também poderia ter gerado por comando, antes de reiniciar.

Enfim, a experiência dos últimos anos já me mostrou que não adianta o Grub de outra distro apontar para o Kernel “generic” do Slackware, — pois o boot acaba em “Kernel panic”.

Inclusão do Slackware no Grub de outra distro

Atualizei o Grub do openSUSE e substituí o parâmetro “generic” por “huge”, no editor interno do Midnight-Commander (mcedit).

Aproveitei para corrigir o fstab do openSUSE com o novo UUID da partição Swap, e ativar com o comando # swapon --all.

Criação do usuário e configuração do Grub no Slackware

No Slackware já instalado, finalmente criei a conta de usuário e gerei o arquivo de configuração do Grub — para ser lido pelo Grub do openSUSE e do Mageia, que uso como Menus de inicialização da máquina.

Não precisava instalar o Grub do Slackware na partição EFI — exceto como uma alternativa para ter à mão — mas se embaralhou com o Grub de outro Slackware (by AlienBOB), instalado em outra partição (sda11) no ano passado.

Detalhe (Acima) - O arquivo grubx64.efi gerado em 18 Fev. 2021 (UTC) foi para a pasta criada ao instalar o Slackware (by AlienBOB) em 26 Set. 2020. — Para diferenciá-los, terei de especificar uma pasta com outro nome, talvez usando parâmetros como # grub-install (...) --bootloader-id=Slackware15 --recheck, para diferenciar (Estudar, antes!).

Configurações

xxxx

Nas primeiras horas, me limitei às configurações mais simples, — Relógio, Tema, Estilo, Decoração das janelas, Sessão KDE, — até configurar a montagem automática de partições adicionais, onde guardo inúmeras anotações.

Sim, quase todas anotações estão aqui no blog, mas dispersas em dezenas de postagens. É bem mais cômodo procurá-las em um único arquivo, onde estão reunidas.

Para autorizar a montagem de partições adicionais pelo usário, sem autenticação:

/etc/polkit-1/rules.d/99-udisks2.rules

// 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; } });

Para garantir que os pontos de montagem sejam deletados ao final de cada sessão e recriados no início, adotar a opção “0” em:

/etc/udev/rules.d/99-udisks2.rules

# UDISKS_FILESYSTEM_SHARED
# ==1: mount filesystem to a shared directory (/media/VolumeName)
# ==0: mount filesystem to a private directory (/run/media/$USER/VolumeName)
# See udisks(8)
ENV{ID_FS_USAGE}=="filesystem|other|crypto", ENV{UDISKS_FILESYSTEM_SHARED}="0"

xxxx

A configuração global “Montar automaticamente todas as mídias removíveis (partições adicionais) no Login” pareceu não fazer efeito, — exceto para algumas partições (Depot1, Warehouse), que talvez eu já tivesse montado manualmente, antes de reiniciar a sessão KDE.

xxxx

Após substituir a configuração “global” pela configuração “individual” de todas as partições adicionais, finalmente a montagem automática funcionou ao reiniciar a sessão KDE.

xxxx

Baixadas as fotos da instalação pelo KDE Connect.

xxxx

Solucionando o início do Plasma KDE

Durante alguns dias, precisei fazer Login no console virtual (tty1) e executar $ startx para entrar no KDE. — Só após alterar o runlevel de 3 para 4, em /etc/inittab, o SDDM conseguiu carregar o KDE automaticamente, no final do boot.

xxxx

— … ≠ • ≠ … —

Without-SystemD

PC desktop UEFI / GPT

Ferramentas &tc.

Grub enlouquecido com 12 distros em multiboot

Não-debians

Adicionando HDD a 11 distros Linux em dualboot

noreply@blogger.com (Mboaba) — Tue, 12 Jan 2021 19:29:00 +0000

Terceiro HDD 3½’’, no “piso” da grade para dispositivos 5¼’’

• Instalar mais um Hard Disk Drive (HDD) em um PC Desktop é coisa banal, e por si só, não mereceria uma postagem de blog.

Mas, já faz algum tempo que sinto a falta de um registro (para lembrar) da rotina básica que adotei para manutenção de múltiplas distros em dualboot.

Índice

HDD adicional
Configurar nas distros
Ordem inversa
Nova partição
Reconfigurações

Linux8
Linux7
Linux6
Linux5
Linux4
Linux3
Linux2
Linux12
Linux11
Linux10
Linux9
Linux1

Luckybackup
Outros backups

HDD adicional

Hard disk drive (HDD) adicional, no UEFI Bios Setup

Ao escolher o gabinete para o novo computador, me pareceu que oferecesse alojamento interno (slots) para até 5 HDDs de 3½’’. — Eu tinha 3 HDDs antigos, que pretendia aproveitar durante algum tempo, até comprar outros mais novos.

Só ao chegar em casa, percebi que 3 daqueles espaços 3½’’ estavam previamente inutilizados, pela péssima disposição (vertical!) destinada ao SSD interno. — Por isso, acabei instalando apenas 2 HDDs, no ano passado.

Agora, um ano depois, percebi que o “piso” da estante para dispositivos 5¼’’ oferecia umas rebarbas para fixar mais um dispositivo de 3½’’. — Desliguei toda a energia e aparafusei lá meu 3º HDD.

Hard disk drive (HDD) adicionado

Os conectores Sata III da placa-mãe se contam do alto para baixo — em 3 linhas horizontais — e da direita para a esquerda, em cada linha (item 7, abaixo).

Ordem dos conectores Sata

Para o técnico, fazia sentido plugar o CD-DVD logo após o SSD, — que era então a única “unidade de disco”, — e quando comecei a plugar os HDDs esqueci de mudar o CD-DVD para o final.

De qualquer modo, o Linux entende assim, — primeiro os “discos” fixos; depois o USB externo, — e o DRW à parte:

$ inxi -d

Local Storage:                total:    2.84 TiB          used: 838.23 GiB   (28.8%)

  Sata #1   ID-1: /dev/sda   SSD  Sata3  Kingston  SA400S37480G        447.13 GiB   480 GB
  Sata #3   ID-2: /dev/sdb   HDD  Sata3  Seagate   ST1000DM003-1SB102  931.51 GiB   1   TB  (2016)
  Sata #4   ID-3: /dev/sdc   HDD  Sata2  Maxtor    STM3320613AS        298.09 GiB   320 GB  (2008)
  Sata #5   ID-4: /dev/sdd   HDD  Sata2  Samsung   HD322HJ             298.09 GiB   320 GB  (2008)
  USB ext   ID-5: /dev/sde   SSD  USB2   Samsung   S2 Portable         931.51 GiB   1   TB  (2011)

Optical-1: /dev/sr0   DRW  Sata3  ASUS      DRW-24F1MT

Configurar nas distros

Substituição de partição por outra maior

Meu objetivo era criar nesse HDD adicional uma uma partição de bom tamanho, para substituir a acanhada partição de 65 GiB (Storage) que eu tinha improvisado em Janeiro 2020 para atividades do dia-a-dia, — e que já estava se tornando insuficiente. — Depois, ajustar todas as distros a essa nova configuração.

Em resumo, eu precisava carregar as 11 distros Linux, uma após outra:

Na primeira distro: — Criar uma partição de bom tamanho (“Warehouse”) nesse HDD conectado por último

Mover para ela o conteúdo de “Storage”

Em todas as distros: - Configurar “Warehouse” — em vez de “Storage” — para:

Automount

PrtScn

Dolphin (startup)

Kate (session)

Conky

Na última distro: — Deletar a partição “Storage”, agora esvaziada; e

Configurar o Luckybackup para a nova partição “Warehouse”

Por motivos práticos, sigo a ordem inversa do Grub.

Ordem inversa

Sequência do final para o início do Grub

Para lidar de modo racional com as 11 distros Linux instaladas, adotei o hábito de sempre começar pela “última”, — seja para atualizar, ou para qualquer alteração geral, — e terminar com a “primeira”, openSUSE, que controla o Grub (e o Luckybackup).

Desse modo, o Grub do openSUSE pode detectar mudanças de Kernel nas outras distros, atualizadas antes dele.

Isso é prático, pois o Grub está configurado para selecionar automaticamente a última distro carregada, — e basta ir movendo a seleção para cima, a cada novo boot.

Acontece que o Grub organiza a sequência das distros pelo ordem alfa-numérica dos respectivos dispositivos, — ou seja, primeiro /dev/sda2 (porque o Grub pertence ao openSUSE); — depois, sda10, sda11, sda13, — e por fim, sda3, sda4 etc.:

Grub, by alphanumeric /dev order

├─sda2    50G  Linux1     openSUSE
├─sda10   30G  Linux9     Void
├─sda11   30G  Linux10    Slackware
├─sda12   30G  Linux11    -
├─sda13   30G  Linux12    MX Linux
├─sda3    30G  Linux2     Arch
├─sda4    30G  Linux3     Debian
├─sda5    30G  Linux4     Fedora
├─sda6    30G  Linux5     KDE Neon
├─sda7    30G  Linux6     PCLinuxOS
├─sda8    30G  Linux7     Mageia
└─sda9    30G  Linux8     Mint

Portanto, foi esta a ordem que segui, ao percorrer todas as distros, — começando pelo Linux Mint (com KDE), que é a “última”, no Grub, — até chegar ao openSUSE, que é a “primeira”.

Nova partição

Antigo SSD externo USB2 deslocado para /dev/sdde

Ao iniciar o Linux Mint 20 (com KDE), o recém-plugado HDD 320 GB (298 GiB) tomou o “lugar” de /dev/sdd, com reflexos no uDisks2, visíveis no painel lateral do Dolphin.

Por isso, a partição “Depot2”, do SDD externo USB, deixou de ser montada automaticamente pelo uDisks2. — Agora, o SSD externo USB é /dev/sde, — coisa que não estava prevista, e por isto sua montagem automática não se realizou.

Atividade intensa de Read / Write, até desmontar a partição do 3º HDD

Em troca, ocorreu a montagem automática de uma partição vazia, sem rótulo (Label), existente no “novo” HDD, — devido à configuração que uso no KDE System Settings / uDisks2.

Por ser a primeira vez que foi montada, isso causou intensa atividade de Read / Write, — que só cessou ao ser “desmontada” (unmount).

Alterando a tabela de particionamento, de MBR (msdos) para GPT

O 3º HDD estava particionado como MBR (msdos), porque eu pretendia deixá-lo no antigo PC Desktop, — mas para usá-lo no novo PC, achei melhor convertê-lo logo em GPT.

Criando a nova partição de dados “Warehouse”

Em seguida, criei nele uma partição de 240 GiB, com rótulo (Label) “Warehouse”, — para substituir “Storage” (65 GiB), criada provisoriamente em Janeiro 2020, e que já estava com pouco espaço livre.

Montagem automática da nova partição

Habilitei a montagem automática da nova partição “Warehouse” e reiniciei a sessão KDE (Logout / Login), para conferir o resultado, antes de prosseguir com as demais configurações.

Atividade de “ext4-rsv-convert” da nova partição montada

A atividade de “Writeback conversion work” (ext4-rsv-convert), após a primeira montagem da partição recém-criada, se completou em cerca de 9 minutos.

Movendo (quase) tudo para a nova partição

Movi as pastas da antiga partição “Storage” para a nova partição “Warehouse”, — exceto a pasta “PrtScn”, cujo conteúdo também movi, mas deixei (vazia), para que todas as distros ainda pudessem salvar Capturas de tela, até que a última fosse reconfigurada.

Reconfigurações

Nova localização (path) para salvar as Capturas de tela

Linux8 - Depois de configurar PrtScn para salvar na nova partição, bastava levar para lá as últimas Capturas de tela gravadas na antiga.

Configurações do Dolphin e da sessão do Kate

No Dolphin, mudei a “página inicial”, — da antiga para a nova partição.

No Kate, reabri os mesmos documentos de antes, agora em sua nova localização (path), — de modo que, ao abri-lo, a “sessão” já venha completa.

Os arquivos da minha “sessão-padrão” do Kate são as “anotações” de cada distro (Notes_01 ~ Notes_12, conforme o caso); “Diversos” (comandos, parâmetros etc. que uso muito); “Speedtest” e “IPv6” (registros diários do estado da conexão); Códigos do Blogger que o editor online não oferece; e as configurações das 2 instâncias do Conky de cada distro, que edito com certa frequência.

Substituição da antiga partição pela nova, no Conky

Enfim, substituí no Conky a antiga partição “Storage” pela nova partição “Warehouse”.

Deletando uma partição sem utilidade

Linux7 - No Mageia, a nova partição “Warehouse” também já foi automaticamente montada no início da sessão KDE, — devido à configuração do System settings / uDisks2, — e pude passar logo às demais configurações.

Aproveitei para deletar uma partição “eBooks”, que era só uma poluição visual. — Nunca cheguei a usar, nem coloquei em montagem automática, em nenhuma das distros. — Eliminá-la não daria nenhum trabalho adicional.

Configuração do Dolphin e do atalho PrtScn no PCLinuxOS

Linux6 - Também no PCLinuxOS a nova partição “Warehouse” foi automaticamente montada, e passei logo às configurações do Dolphin, PrtScn etc.

Configuração de montagem automática de /dev/sdd1

Linux5 - Tudo parece confirmar que a montagem automática da nova partição “Warehouse” se deve a ter “herdado” a configuração de uDisks2 para /dev/sdd1, — antes atribuída à partição “Depot2”, do SSD externo USB, que agora é /dev/sde1.

A opção de montagem automática ao plugar (On Attach), na coluna da direita, eu só uso para esse SSD externo USB, — que eventualmente pode estar desconectado durante o boot; — ou ser desmontado para plugar o velho scanner USB, e plugado de novo mais tarde.

Configuração do Conky para exibir a nova partição

Linux4 - As re-configurações não apresentaram novidade no Fedora.

Senha para montagem, no Debian

Linux3 - No Debian, foi solicitada senha para montagem pelo uDisks2, — que nessa distro, eu só usava para o SSD externo USB, — até então “localizado” em /dev/sdd, onde agora está o “novo” HDD interno.

Desabilitei a montagem de “Warehouse” pelo System settings / uDisks2, — pois isso será feito pelo /etc/fstab.

Montagem da nova partição pelo /etc/fstab

No /etc/fstab, acrescentei uma linha para a montagem de “Warehouse”, até refazer as demais configurações.

Após as demais reconfigurações (Dolphin, Kate, PrtScn, Conky), anulei a linha referente a “Storage”, — para evitar falha de boot, depois que essa partição for deletada.

Montagem automática da nova partição no Arch Linux

Linux2 - No Arch Linux, também ocorreu a montagem automática pelo uDisks2, nas opções gerais (no alto), de montar todas as mídias removíveis “no Login” e “ao Plugar”, — onde “removível” se refere a tudo que não sejam partições do sistema, — tais como /, /home, Swap etc.

Note que, no Arch, não usei a habilitação individual, nas 2 colunas à direita. — Mesmo que usasse, só teria efeito, se desativasse as 2 opções gerais, no alto, — pois estas se sobrepõem às opções individuais.

Em outras distros, tive o trabalho de testar ambas alternativas, — e os resultados observados agora, com a montagem automática de uma partição “inesperada” (sem prévia configuração individual) mostrou a vantagem das habilitações gerais.

Montagem automática de partições no MX Linux

Linux12 - No MX Linux, a montagem automática se deu pela configuração geral no uDisks2, — que se sobrepõe à habilitação individual das partições. — Desmarquei “Warehouse”.

Embora seja um “Debian” (sem SystemD), a montagem pelo usuário pode ser autorizada pelo MX Tweaks, — e por isso eu já tinha anulado dezenas de linhas no /etc/fstab.

Linux11 - Ainda não instalei nenhum “Linux11”. — Deveria ser o Sabayon, mas essa distro está em um momento de transição, no qual ainda não consegui me situar.

Montagem automática e re-configuração do KDE Spectacle

Linux10 - No Slackware (by AlienBOB, com KDE5), a nova partição “Warehouse” também foi montada automaticamente, — deixando claro que eu não precisava usar o /etc/fstab, lado a lado com o uDisks2.

Aproveitei para reconfigurar logo o KDE Spectacle, o Dolphin (startup), o Kate (session), e o Conky.

Desabilitando a montagem pelo fstab

Não faz sentido, usar o /etc/fstab, em conjunto com uDisks2. — Bom... Isso já estava claro, em Setembro 2020, quando instalei o Slackware, e percebi que a autorização para montagem de partições adicionais sem autenticação, finalmente, funcionou (o que não acontecia até 2019):

/etc/polkit-1/rules.d/99-udisks2.rules

// 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; } });

Só que, em Setembro 2020, não consegui mais que uDisks2 funcionasse, após desabilitar a montagem das partições adicionais pelo fstab. — Deixei para depois, — e agora, chegou o momento de enfrentar o problema.

Deletando pontos de montagem, a partir de outra distro

Em resumo, os pontos de montagem criados pelo fstab (root) não foram automaticamente deletados ao sair do Slackware, — e ao entrar de novo, uDisks2 (user) precisou criar duplicatas: — “Linux71”, para substituir “Linux7”, por exemplo.

Por algum motivo, isso também afetou a montagem do SSD externo USB, — que não estava incluído no /etc/fstab. — Encontrei agora dezenas de pontos de montagem “Depot2”, ”Depot21”, “Depot218”, “Depot225” etc., acumulados ao longo dos meses.

Seria uma insanidade, tentar consertar isso dentro do próprio Slackware. — Em geral, recomenda-se usar uma sessão Live, onde todas essas partições “extras” estejam desmontadas. — Como tenho várias distros em dualboot, achei mais confortável usar o openSUSE, que oferece Krusader em modo superusuário (Krusader as Root), para deletar essas dezenas de pontos de montagem do Slackware.

Com isso, a montagem automática pelo uDisks2 finalmente funcionou por si só, — mas ao reiniciar uma vez, duas vezes, o problema voltou a ocorrer, — e não faz sentido usar o openSUSE para deletar os pontos de montagem, a cada reinício do Slackware.

Mudando o local dos pontos de montagem

Além disso, a pasta /media do Slackware abriga vários pontos de montagem típicos do sistema (cdrom, dvd, floppy, cdrecorder, memory, hd), — e me ocorreu reverter os pontos de montagem das partições extras para /run/media/flavio.

Bastou reverter de “1” para “0” a opção em /etc/udev/rules.d/99-udisks2.rules:

# UDISKS_FILESYSTEM_SHARED
# ==1: mount filesystem to a shared directory (/media/VolumeName)
# ==0: mount filesystem to a private directory (/run/media/$USER/VolumeName)
# See udisks(8)
ENV{ID_FS_USAGE}=="filesystem|other|crypto", ENV{UDISKS_FILESYSTEM_SHARED}="0"

Isso parece ter resolvido definitivamente o problema, — pois a subpasta /run/media é deletada ao encerrar o Slackware, eliminando assim todos os pontos de montagem, permitindo recriá-los ao iniciar a distro outra vez.

Uma comparação das duas pastas mostra permissões diferentes entre os novos pontos de montagem (em uso) e os antigos (inativos), — por motivos que, agora, uma pesquisa talvez esclareça com mais facilidade:

# ls -n /run/media/flavio/
total 104
drwxr-xr-x 12    0    0 4096 Aug 16 14:44 Depot1
drwxr-xr-x 12    0    0 4096 Aug 19 13:30 Depot2
drwxr-xr-x  3    0    0   20 Nov 26 19:42 Home1
drwxr-xr-x  3    0    0 4096 Feb 26  2020 Home11
drwxr-xr-x  4    0    0 4096 Jul 22  2020 Home12
drwxr-xr-x  4    0    0 4096 Apr 15  2020 Home2
drwxr-xr-x  4    0    0 4096 Apr  1  2020 Home3
drwxr-xr-x  4    0    0 4096 Jul 27  2020 Home4
drwxr-xr-x  4    0    0 4096 Mar  8  2020 Home5
drwxr-xr-x  4    0    0 4096 Mar  8  2020 Home6
drwxr-xr-x  5    0    0 4096 Jul 31 10:14 Home7
drwxr-xr-x  4    0    0 4096 Jun 12  2020 Home8
drwxr-xr-x  4    0    0 4096 Jul 13  2020 Home9
drwxr-xr-x  1    0    0  204 Aug  4 23:29 Linux1
drwxr-xr-x  3    0    0 4096 Jan 14  2020 Linux11
drwxr-xr-x 20    0    0 4096 Nov 19 14:37 Linux12
drwxr-xr-x 17    0    0 4096 Jan 22 15:58 Linux2
drwxr-xr-x 18    0    0 4096 Jan 10 22:21 Linux3
dr-xr-xr-x 20    0    0 4096 Oct 28 22:25 Linux4
drwxr-xr-x 24    0    0 4096 Jul 29 13:12 Linux5
drwxr-xr-x 26    0    0 4096 Jan 22 15:24 Linux6
drwxr-xr-x 19    0    0 4096 Aug  2 14:01 Linux7
drwxr-xr-x 23    0    0 4096 Jun 12  2020 Linux8
drwxr-xr-x 17    0    0 4096 Jan 26 10:42 Linux9
drwxr-xr-x  5 1000    0 4096 Apr 27  2019 Sites
drwxr-xr-x 13 1000 1000 4096 Jan 10 20:02 Warehouse
drwxr-xr-x 19 1000    0 4096 Jul 17  2019 Works
drwxr-xr-x 14 1000    0 4096 Oct 26  2019 XTudo

# ls -n /media/
total 284
drwx------ 2 0 0 4096 Jan 26 12:41 Depot1
drwx------ 2 0 0 4096 Jan 26 12:47 Depot11
drwx------ 2 0 0 4096 Jan 26 12:41 Depot2
drwx------ 2 0 0 4096 Jan 26 12:47 Depot21
drwx------ 2 0 0 4096 Jan 26 12:41 Home1
drwx------ 2 0 0 4096 Jan 26 12:41 Home11
drwx------ 2 0 0 4096 Jan 26 12:47 Home111
drwx------ 2 0 0 4096 Jan 26 12:41 Home12
drwx------ 2 0 0 4096 Jan 26 12:47 Home121
drwx------ 2 0 0 4096 Jan 26 12:47 Home13
drwx------ 2 0 0 4096 Jan 26 12:41 Home2
drwx------ 2 0 0 4096 Jan 26 12:47 Home21
drwx------ 2 0 0 4096 Jan 26 12:41 Home3
drwx------ 2 0 0 4096 Jan 26 12:47 Home31
drwx------ 2 0 0 4096 Jan 26 12:41 Home4
drwx------ 2 0 0 4096 Jan 26 12:47 Home41
drwx------ 2 0 0 4096 Jan 26 12:41 Home5
drwx------ 2 0 0 4096 Jan 26 12:47 Home51
drwx------ 2 0 0 4096 Jan 26 12:41 Home6
drwx------ 2 0 0 4096 Jan 26 12:47 Home61
drwx------ 2 0 0 4096 Jan 26 12:41 Home7
drwx------ 2 0 0 4096 Jan 26 12:47 Home71
drwx------ 2 0 0 4096 Jan 26 12:41 Home8
drwx------ 2 0 0 4096 Jan 26 12:47 Home81
drwx------ 2 0 0 4096 Jan 26 12:41 Home9
drwx------ 2 0 0 4096 Jan 26 12:47 Home91
drwx------ 2 0 0 4096 Jan 26 12:41 Linux1
drwx------ 2 0 0 4096 Jan 26 12:41 Linux11
drwx------ 2 0 0 4096 Jan 26 12:47 Linux111
drwx------ 2 0 0 4096 Jan 26 12:41 Linux12
drwx------ 2 0 0 4096 Jan 26 12:47 Linux121
drwx------ 2 0 0 4096 Jan 26 12:47 Linux13
drwx------ 2 0 0 4096 Jan 26 12:41 Linux2
drwx------ 2 0 0 4096 Jan 26 12:47 Linux21
drwx------ 2 0 0 4096 Jan 26 12:41 Linux3
drwx------ 2 0 0 4096 Jan 26 12:47 Linux31
drwx------ 2 0 0 4096 Jan 26 12:41 Linux4
drwx------ 2 0 0 4096 Jan 26 12:47 Linux41
drwx------ 2 0 0 4096 Jan 26 12:41 Linux5
drwx------ 2 0 0 4096 Jan 26 12:47 Linux51
drwx------ 2 0 0 4096 Jan 26 12:41 Linux6
drwx------ 2 0 0 4096 Jan 26 12:47 Linux61
drwx------ 2 0 0 4096 Jan 26 12:41 Linux7
drwx------ 2 0 0 4096 Jan 26 12:47 Linux71
drwx------ 2 0 0 4096 Jan 26 12:41 Linux8
drwx------ 2 0 0 4096 Jan 26 12:47 Linux81
drwx------ 2 0 0 4096 Jan 26 12:41 Linux9
drwx------ 2 0 0 4096 Jan 26 12:47 Linux91
-rw-r--r-- 1 0 0  500 Sep 26  2006 README
drwx------ 2 0 0 4096 Jan 26 12:41 Sites
drwx------ 2 0 0 4096 Jan 26 12:47 Sites1
drwx------ 2 0 0 4096 Jan 26 12:41 Warehouse
drwx------ 2 0 0 4096 Jan 26 12:47 Warehouse1
drwx------ 2 0 0 4096 Jan 26 12:41 Works
drwx------ 2 0 0 4096 Jan 26 12:47 Works1
drwx------ 2 0 0 4096 Jan 26 12:41 XTudo
drwx------ 2 0 0 4096 Jan 26 12:47 XTudo1
lrwxrwxrwx 1 0 0   11 Sep 22 09:24 cdrecorder -> cdrecorder0
drwxr-xr-x 2 0 0 4096 Sep 25  2006 cdrecorder0
drwxr-xr-x 2 0 0 4096 Sep 25  2006 cdrecorder1
lrwxrwxrwx 1 0 0    6 Sep 22 09:24 cdrom -> cdrom0
drwxr-xr-x 2 0 0 4096 Sep 25  2006 cdrom0
drwxr-xr-x 2 0 0 4096 Sep 25  2006 cdrom1
lrwxrwxrwx 1 0 0    4 Sep 22 09:24 dvd -> dvd0
drwxr-xr-x 2 0 0 4096 Sep 25  2006 dvd0
drwxr-xr-x 2 0 0 4096 Sep 25  2006 dvd1
lrwxrwxrwx 1 0 0    7 Sep 22 09:24 floppy -> floppy0
drwxr-xr-x 2 0 0 4096 Sep 25  2006 floppy0
drwxr-xr-x 2 0 0 4096 Sep 25  2006 floppy1
lrwxrwxrwx 1 0 0    3 Sep 22 09:24 hd -> hd0
drwxr-xr-x 2 0 0 4096 Sep 25  2006 hd0
drwxr-xr-x 2 0 0 4096 Sep 25  2006 hd1
lrwxrwxrwx 1 0 0    7 Sep 22 09:24 memory -> memory0
drwxr-xr-x 2 0 0 4096 Sep 25  2006 memory0
drwxr-xr-x 2 0 0 4096 Sep 25  2006 memory1
lrwxrwxrwx 1 0 0    4 Sep 22 09:24 zip -> zip0
drwxr-xr-x 2 0 0 4096 Sep 25  2006 zip0
drwxr-xr-x 2 0 0 4096 Sep 25  2006 zip1

Montagem automática da nova partição

Linux9 - A montagem automática da nova partição “Warehouse” também ocorreu no Void Linux, — e alterei logo as configurações do Dolphin, Kate, Conky, PrtScn.

Partições para o KDE System settings “esquecer”

A partição Depot2 não foi montada, — pois agora é /dev/sde1, o que não estava previsto no uDisks2.

Estranhei a quantidade de partições não encontradas (Disconnected devices), duplicadas, — sinal de alguma coisa estranha. — Tratei de mandar esquecê-las.

Note que eu havia adotado uma configuração diferente, — com habilitação individual no Login (à direita), para partições dos discos internos, — e habilitação geral (no alto) para dispositivos externos, ao plugar (On Attach).

Informações defasadas em /run/blkid/blkid.tab

Ao reiniciar o Void Linux várias vezes, a montagem automática continuou a apresentar várias falhas, por vários dias seguidos, apesar de todas as tentativas para corrigir isso.

Sem conhecimentos aprofundados do Linux, a única possível causa que encontrei foi o arquivo /run/blkid/blkid.tab — inalterado desde a instalação do Void Linux, em 13 Julho 2020 — onde o identificador UUID da partição “Depot2”permanecia atrelado a /dev/sdd1; onde permanecia a lembrança da partição “Storage”, já deletada; e quem sabe quais outros possíveis erros.

Renomeei o arquivo, e ao reiniciar, o Void Linux gerou outro “blkid.tab”.

Problema aparentemente resolvido

Mesmo então, a montagem automática ainda apresentou falhas, — até que montei manualmente todas as partições restantes, pelo Dolphin. — Depois disso, ainda houve algumas falhas, no dia 21, mas não se repetiram mais, do dia 22 em diante.

Em tempo: - No Void não existe /etc/udev/rules.d/99-udisks2.rules

Luckybackup

Renomeando backups da antiga partição “Storage” para “Warehouse”

Linux1 - Após concluir no openSUSE as reconfigurações comuns a todas as distros, era hora de adaptar os backups à nova situação.

Primeiro, renomeei as pastas “Storage” (com os backups já existentes) para “Warehouse”, nas partições Depot1 e Depot2:

Depot1/Backup/Warehouse
Depot2/Backup/Warehouse

(onde o segundo é uma cópia do backup da semana anterior).

Perfil 1 - cópia do backup anterior

Isso dispensou o Luckybackup de copiar novamente (por duas vezes) todo o conteúdo existente em “Warehouse”, — que afinal, é o mesmo conteúdo da antiga partição “Storage”, com alguns acréscimos e alterações da última semana.

Perfil 2 - atualização do backup das partições de dados

No segundo perfil do Luckybackup, apenas renomeei e reconfigurei o item “Storage”, que agora passa a fazer o backup de “Warehouse”.

2021-01-11 ───> Luckybackup

Profiles:

1) Depot1 --> Depot2

Depot1                             Depot2
   ├── Backup              ───>       ├──
   ├── Distros Linux       ───>       ├──
   ├── Sites_backups       ───>       ├──
   ├── Colab               ───>       ├──
   ├── Fotos digitais      ───>       ├──
   ├── Downloads           ───>       ├──
   ├── Biblioteca          ───>       ├──
   ├── AutoCAD, Corel      ───>       ├──
   └── Videos              ───>       └──


2) Partitions --> Depot1

                            Depot1
                               └── Backup
Storage Warehouse  ───>               ├──
Xtudo              ───>               ├──
Works              ───>               ├──
Sites              ───>               └──


Commands:

1) Depot1 --> Depot2

rsync -h --progress --stats -r -tgo -p -l -D --update --delete-after /run/media/flavio/Depot1/Backup /run/media/flavio/Depot2/
rsync -h --progress --stats -r -tgo -p -l -D --update --delete-after /run/media/flavio/Depot1/AutoCAD_Corel-Draw /run/media/flavio/Depot2/
rsync -h --progress --stats -r -tgo -p -l -D --update --delete-after /run/media/flavio/Depot1/Biblioteca /run/media/flavio/Depot2/
rsync -h --progress --stats -r -tgo -p -l -D --update --delete-after /run/media/flavio/Depot1/Colab /run/media/flavio/Depot2/
rsync -h --progress --stats -r -tgo -p -l -D --update --delete-after /run/media/flavio/Depot1/Distros-Linux /run/media/flavio/Depot2/
rsync -h --progress --stats -r -tgo -p -l -D --update --delete-after /run/media/flavio/Depot1/Downloads /run/media/flavio/Depot2/
rsync -h --progress --stats -r -tgo -p -l -D --update --delete-after /run/media/flavio/Depot1/Fotos-digitais /run/media/flavio/Depot2/
rsync -h --progress --stats -r -tgo -p -l -D --update --delete-after /run/media/flavio/Depot1/sites_backups /run/media/flavio/Depot2/

2) Partitions --> Depot1

rsync -h --progress --stats -r -tgo -p -l -D --update --delete-after /run/media/flavio/Warehouse /run/media/flavio/Depot1/Backup/
rsync -h --progress --stats -r -tgo -p -l -D --update --delete-after /run/media/flavio/XTudo /run/media/flavio/Depot1/Backup/
rsync -h --progress --stats -r -tgo -p -l -D --update --delete-after /run/media/flavio/Works /run/media/flavio/Depot1/Backup/
rsync -h --progress --stats -r -tgo -p -l -D --update --delete-after /run/media/flavio/Sites /run/media/flavio/Depot1/Backup/

Deletando a antiga partição, agora vazia

Enfim, desmontei e deletei a antiga partição “Storage”, já esvaziada.

Outros backups

Backup dos arquivos fstab e verificação final

Ao final dessas alterações, fiz um backup dos arquivos /etc/fstab — e também dos arquivos de configuração do Conky.

Uma busca pelo conteúdo, no Dolphin, indicou quais arquivos fstab contêm “Storage”, — e me certifiquei que tais linhas estivessem desativadas (comentadas com “#” no início).

\\\\

— … ≠ • ≠ … —

Ferramentas &tc.

Grub enlouquecido com 12 distros em multiboot

Remanejamento de sistemas Linux ao reparticionar discos

Backup total e limpeza das partições de trabalho
Migrando sistemas Linux para disco rígido de 1 Terabyte
Ensaio de avaliação com luckyBackup e Unison
Particionamento de Drive SSD para vários Linux

Ferramentas mudam cálculo de Memória RAM

noreply@blogger.com (Mboaba) — Tue, 20 Oct 2020 03:25:01 +0000

Comando free assusta testadores do Debian 12 Bookworm RC, em Abril 2023

• Usuários que executaram o comando free para medir o uso inicial de Memória RAM do Debian 12 Bookworm RC, em Abril 2023, levaram um susto: — Quase o dobro do que o free indicava no Debian 11!

Não foi o Debian que mudou. — O que mudou foram as ferramentas free / top, do pacote procps 4.0 — mas isso já vinha ocorrendo com outras ferramentas, pelo menos desde 2020.

Trata-se de um “cálculo novo” — proposto por Linus Torvalds em 2014 — e que só a partir de 2020 começou a ser adotado pelas principais ferramentas, cada uma em um momento diferente:

/proc/meminfo --> (New calc):

Mem used = MemTotal - MemAvailable

ver “Agosto 2020”, adiante.

Vale a pena registrar essas mudanças — bem como as divergências de muitos usuários e desenvolvedores — e os erros de comparação que se cometem a cada dia, pelo uso de ferramentas com cálculos diferentes.

Índice

2017 a 2020
Agosto 2020
Março 2021
Maio 2021
Outubro 2021
Abril 2023
Natal 2023
Abril 2024
Existe vida após o Neofetch
Comparar distros?
Ferramentas e medições

No Conky
Em TXT
Referências

Aplicativos GUI

KSysguard
Terminais
Plasma System Monitor
Gnome System Monitor

2017 a 2020

Paridade de cálculo de uso de Memória RAM, entre Conky e htop, em 2017

Desde 2017, notei que o Conky e o htop indicavam números quase iguais de uso de Memória RAM. — Em meados daquele ano fiz dezenas de testes, em várias distros, e comprovei aquela paridade — exceto no openSUSE Leap, cujo Conky recebia atualizações em ritmo frenético, e sempre discrepava do htop.

O Quadro (acima) é um resumo. Números detalhados estão em “Paridade-RAM-Conky-htop-2017-2020”.

Aquele cálculo — que chamo de “cálculo antigo”, para facilitar — seguia esta fórmula (aproximadamente), a partir dos dados em /proc/meminfo:

/proc/meminfo --> (Old calc):

Mem used = MemTotal - [MemFree + Active(file) + Inactive(file) + SReclaimable]

O arquivo /proc/meminfo contém dezenas de informações acessíveis ao usuário comum — atualizadas o tempo todo — incluindo estas:

$ cat /proc/meminfo | wc --lines
56

$ cat /proc/meminfo | grep 'Mem\|Active\|Inactive\|Reclaimable'
MemTotal:       16222988 kB
MemFree:         9512728 kB
MemAvailable:   11838260 kB
Active:          4013088 kB
Inactive:        1410380 kB
Active(anon):    3098724 kB
Inactive(anon):        0 kB
Active(file):     914364 kB
Inactive(file):  1410380 kB
KReclaimable:     341236 kB
SReclaimable:     341236 kB

Também notei, naquela época, que as ferramentas free e top (do procps) davam números bem menores — como nesse registro de 2019:

Divergência do free e do top em relação ao Conky e ao htop, em 2019

Como meu interesse era só no Conky, nunca pesquisei a fórmula usada naquela época pelo free e pelo top — que vou chamar de “cálculo muito antigo” (se me permitirem), só para facilitar a comunicação.

O inxi tinha um cálculo próprio, só dele — que também não pesquisei.

Agosto 2020

Aumento aparente de uso de RAM, com o Conky 1.11.6

Desde Agosto 2020, o Conky 1.11.6 passou a mostrar valores bem mais altos de uso de Memória RAM — no openSUSE Tumbleweed, Debian testing, Fedora, Mageia 8 (beta), Void Linux. — Foi o “primeiro susto”, digamos assim.

Proposta do “novo cálculo”, em 2014

Não era bug. — Era uma “correção” do cálculo da “Memória RAM usada” — proposta ou subscrita por Linus Torvalds desde Janeiro 2014 (Kernel 3.14), quando se introduziu em /proc/meminfo um campo “MemAvailable”, exatamente para tornar esse cálculo mais acurado:

Currently, the amount of memory that is available for a new workload, without pushing the system into swap, can be estimated from MemFree, Active(file), Inactive(file), and SReclaimable, as well as the "low" watermarks from /proc/zoneinfo.

However, this may change in the future, and user space really should not be expected to know kernel internals to come up with an estimate for the amount of free memory.

It is more convenient to provide such an estimate in /proc/meminfo. If things change in the future, we only have to change it in one place.

Aplicação do “novo cálculo” ao Conky, em 2019

A aplicação dessa mudança no Conky só foi pedida em Junho 2019; — efetuada em Outubro 2019 (acima); — e ainda demorou 10 meses, até o Conky 1.11.6 chegar às principais distros rolling-release (e ao Fedora).

Foi o marco inicial de um movimento (bem atrasado) para um cálculo tecnicamente mais correto — além de bem mais simples e fácil.

Março 2021

Situação após nova reviravolta do Conky

Em Março 2021, o Conky 1.12.1 fez uma reviravolta, — passando a exibir valores muito baixos.

Foi uma rendição (temporária, felizmente) à grita de usuários, que exigiam paridade do Conky com o free / top — no que apelidei de “cálculo muito antigo” (se os experts permitirem). — No fundo, uma ânsia de garantir o troféu de “mais leve” para suas distros.

Com o tempo, no entanto, foi-se delineando um movimento de outras ferramentas rumo ao “cálculo novo” — embora com recuos aqui e ali:

Maio 2021

Uso de Memória RAM segundo várias ferramentas, em Maio 2021

Em Maio 2021, tabulei esse registro (acima) do suposto uso inicial de Memória RAM das distros que eu tinha naquele momento (todas com KDE), para ver o estado das ferramentas naquele momento:

“cálculo novo”
“cálculo antigo”
“cálculo muito antigo”
cálculo específico do inxi

Era o auge das idas-e-vindas do Conky — que chegou a ter pelo menos 4 versões na praça, brigando umas com as outras:

Conky 1.10.8   =  htop   (old calc)        Neon, Mint 20, MX Linux 19
Conky 1.11.6   >  htop   (new calc)        Arch, Debian testing, Mageia 8
Conky 1.12.1   <  htop   (very old calc)   Fedora 33, PCLinuxOS, Void
Conky 1.12.2   >  htop   (new calc)        openSUSE Tumbleweed

Uso de Memória RAM segundo várias ferramentas, em Maio 2021

Acima: - A tabulação permitiu verificar a faixa de variação do “cálculo antigo” em -24% a -34% dos valores indicados pelo “cálculo novo” — e o “cálculo muito antigo” numa faixa de -39% a -56% — enquanto versões anteriores do inxi tinham um cálculo próprio, só dele, na faixa de -37% a -39%.

Uso de Memória RAM segundo várias ferramentas, em Maio 2021

Esse levantamento também facilitou identificar as versões de cada ferramenta, com os diferentes cálculos de uso de Memória RAM:

O inxi já tinha adotado o “cálculo novo”, pelo menos desde sua versão 3.1.00 (2020-11-11) — mas ainda sobreviviam versões anteriores no KDE Neon e no Linux Mint 20 (base: Ubuntu LTS); e no MX Linux 19 (base: Debian stable 10 ”Buster”).

O screenFetch também já tinha adotado o “cálculo novo”, mas não sei exatamente quando. — A versão 3.8.0 (MX Linux 19) ainda mostrava o mesmo valor indicado por free / top — mas o Changelog das versões seguintes (3.9.0, 3.9.1) não registrou essa mudança.

O htop permanecia com seu tradicional “cálculo antigo”

O Neofetch permanecia no “cálculo antigo” — exceto no Slackware, apesar de ser a mesma versão (7.1.0) das outras distros. — Imagino que fosse uma personalização feita pela equipe da distro.

free / top continuavam com o “cálculo muito antigo”

Outubro 2021

Conky, htop, inxi e screenFetch com o “cálculo novo”, Outubro 2021

Até Outubro 2021, outra mudança:

O htop (3.1.0) adotou o “cálculo novo” em 2021-09-21 — e cheguei a ver isso no Arch, no Manjaro, no openSUSE Tumbleweed, no Void — mas foi um fenômeno de curta duração, pois logo se renderia à grita dos usuários, exigindo paridade com o “cálculo muito antigo” do free / top. — Fica o “registro histórico” desse raro momento.

Abril 2023

Uso de RAM, segundo diferentes ferramentas (3 amostras, Abril 2023)

Em Abril 2023 (acima), continuávamos longe de uma padronização no cálculo de uso de Memória RAM — mas 3 ferramentas já usavam o “cálculo novo”, em todas as versões das minhas distros: — Conky, inxi e screenFetch.

O MX Linux utilizava uma versão personalizada do inxi — adaptada para fornecer informações em seu Fórum — e que não consegui acionar pelos comandos comuns às outras distros.

Uso de RAM, segundo diferentes ferramentas (3 amostras, Abril 2023)

Além disso, o pacote procps 4.0 anunciava a adesão do free / top ao “cálculo novo”, no Debian testing.

Uso de RAM, segundo diferentes ferramentas (3 amostras, Abril 2023)

Na verdade, o procps 4.0 adotou o “cálculo novo” em 2022-06-24 — e já tinha chegado ao Debian testing por volta do Natal:

procps (2:4.0.2-1) unstable; urgency=medium

  * free: Used memory is Total - Available
    This means versions of free after 4.0.0 will show different Used
    values for older frees and some other system utilities.

 -- Craig Small [csmall@debian.org]  Mon, 05 Dec 2022 21:34:57 +1100

Enfim, desde Junho 2022, o openSUSE Tumbleweed já tinha alterado seu free / top 3.3.17 para o “cálculo novo” — sem esperar a versão 4.0.

Na contra-mão desse movimento geral, a versão 3.1.1 (2021-10-14) do htop cedeu à grita dos usuários e retrocedeu para o “cálculo muito antigo” — mas em algumas distros (KDE Neon, Mageia 8, MX Linux 21) ainda sobrevivia o htop 3.0.5, com o “cálculo antigo”.

Portanto, quando o htop recuou para o “cálculo muito antigo” — o free / top já se movimentava para o “cálculo novo”.

Natal 2023

Uso de Memória RAM segundo várias ferramentas, no Natal 2023

Com o rápido avanço das distros para o pacote procps 4.0, desenha-se para breve um quadro — em que apenas o Neofetch e o htop insistirão em manter o “cálculo antigo” e o “muito antigo”, respectivamente.

Uso de Memória RAM segundo várias ferramentas, no Natal 2023

Em 8 das minhas 12 distros (*), free / top já usam o “cálculo novo” — e esse número talvez fosse maior, se eu atualizasse o Slackware e o Redcore. — Restam o KDE Neon (base: Ubuntu LTS) e o PCLinuxOS.

(*) Considero o KDE Neon User Edition e o KDE Neon Unstable como 1 só distro, pois a base é a mesma (Ubuntu LTS 22.04), mudando só a versão do KDE.

Uso de Memória RAM segundo várias ferramentas, no Natal 2023

Dentro de alguns meses, portanto, prevejo 5 ferramentas com o “cálculo novo” em todas as minhas distros — e apenas Neofetch e htop com cálculos diferentes.

Abril 2024

Neofetch descontinuado, após quase 4 anos sem manutenção

26 Abril 2024 - O repositório do Neofetch no Github foi arquivado por seu proprietário, tornando-se “read-only”. — Uma mensagem no seu perfil (Have taken up farming) sugere uma mudança de vida.

A última versão lançada é a 7.1.0, de 2 Agosto 2020. — Ficaram 293 “problemas” (issues) em aberto — e 198 pedidos não atentidos.

Uso de Memória RAM segundo várias ferramentas, em Abril 2024

Só então, percebi que o htop tinha mudado — mais uma vez! — De volta para o “cálculo antigo”, que usava no período 2017-2020 (pelo menos).

Infelizmente, ainda não consegui perceber, no changelog do htop, em qual versão aconteceu essa reviravolta.

Uso de Memória RAM segundo várias ferramentas, em Abril 2024

Retirei desse monitoramento as distros que não estou atualizando — o KDE Neon “Plasma 5”, o Slackware e o Redcore — e com isso, ficou mais nítido o avanço dessas ferramentas rumo à padronização do cálculo de Memória RAM usada.

Uso de Memória RAM segundo várias ferramentas, em Abril 2024

É impossível prever quando o Neofetch começará a “desaparecer” — afinal, ele continua funcionando, pelo menos na aparência — e a inércia é um dos atributos da liberdade, que nos permite dispor de centenas de distribuições Linux.

Existe vida após o Neofetch

Uso de RAM, segundo ferramentas “fetch” que usam o “cálculo novo” — ou não

Não costumo fazer capturas de tela com ferramentas “fetch” para provar que “meu Arch é mais leve, BTW” — até porque sei que não é. — Meu interesse é monitorar o comportamento das ferramentas mais usadas nos fóruns, grupos, comunidades, para exibir o “uso de Memória RAM”.

O arquivamento do Neofetch chamou atenção para as alternativas — e tudo indica que o Fastfetch tende a ser a mais popular — por ser super-rápido, exibir o máximo de informações, e ser altamente configurável. — E felizmente, usa o “cálculo novo”.

O Neofetch parou? Viva o Fastfetch!

Nas distros que oferecem o Fastfetch, retirei o screenFetch e o Neofetch

Não faz sentido encher o Conky com dados de uso de Memória RAM de uma dúzia de ferramentas que ninguém usa. — Por isso, deixei só o Fastfetch nas distros em cujos repositórios ele já está presente — e nas outras, mantive o screenFetch e o Neofetch, que ainda estão presentes no maior número de repositórios.

Comparar distros?

Uso inicial de Memória RAM, pelo cálculo “MemTotal - MemAvailable”

A meu ver, comparações entre diferentes distros Linux só fazem sentido, se todos utilizarem o mesmo “cálculo” — e o mesmo DE. — E qualquer comparação entre diferentes DEs só faz sentido, quando se usa a mesma distro e o mesmo cálculo.

Usando KDE Plasma, há muito tempo me dei conta de que minhas distros mais “leves” costumavam ser o Void, o PCLinuxOS, o Slackware e o Redcore (Gentoo). — Eu poderia ser tentado a dizer “distros sem-SystemD” — caso o Manjaro não se intrometesse no meio — e MX Linux não estivesse, hoje, na “3ª divisão”, das distros que mais usam Memória RAM.

No 2º grupo, “intermediário”, estão o Arch (onde instalei só o que preciso; e o Manjaro); — o Mageia Cauldron (do qual eliminei tudo que pude); — e o KDE Neon (que sempre foi mais “enxuto” do que o Kubuntu padrão).

Ora, no 1º grupo, o Void também é uma instalação “enxuta” — assim como o PCLinuxOS Darkstar. — A ausência de “inchaço” (bloat), me parece a melhor explicação para o menor uso de Memória RAM (com ou sem SystemD).

Em contrapartida, o “inchaço” (bloat) do openSUSE e do Fedora parece valer cada byte utilizado — pelo que acrescenta de vantagens para o usuário — embora nem sempre eu queira todas essas “vantagens”.

Enfim, o gráfico (acima) foi feito a partir de 1 única amostragem. — Isso poderia ser diferente, numa média de 3+ amostragens, pois os números costumam variar, de um boot para outro (e também, a cada segundo).

Ferramentas e medições

Monitorando as ferramentas pelo Conky

À medida em que o Conky e as demais ferramentas entravam nessa fase de mudanças — e seus números perdiam consistência entre as distros — adotei o “cálculo novo”, feito por meus próprios scripts.

No Conky

Calculando o uso de RAM para monitorar as ferramentas

Optei por exibir esse “cálculo novo” no meu Conky2 — encabeçando os números das demais ferramentas — para consultá-los ao vivo — e deixá-los documentados nas Capturas de tela:

conky.config = {
 (...)
 update_interval = 10,
 (...)
}
conky.text = [[
Mem:               ${alignr 100}up  ${uptime}

Total - Available  ${alignr 100}${exec bash MemInfo.sh; cat MemInfo.txt}
Conky (Mem)        ${alignr 100}${mem}
free               ${alignr 100}${exec free -m | grep Mem | cut -c 25-35} MiB
top                ${alignr 100}${exec top -E m -b -n 1  | grep buff | cut -c 41-50} MiB
neofetch           ${alignr 100}${exec neofetch  --stdout | grep -o -P '.{0,0}Memory.{0,9}' | cut -b 8-12} MiB
htop               ${alignr 100}${exec export TERM=xterm; echo q | htop | aha --line-fix | html2text | grep -o -P '.{0,6}/15' | cut -b 1-6}iB
inxi               ${alignr 100}${exec inxi --memory-short | grep -o -P '.{0,0}used.{0,14}' | cut -b 6-14}
screenfetch        ${alignr 100}${exec screenfetch -n -N | grep -o -P '.{0,0}RAM.{0,9}' | cut -b 5-12}
(...)
${alignr}${cat done.txt}  ${execi 600 echo $XDG_SESSION_TYPE}
(...)
]]

Na linha “Total - Available” (acima), o Conky executa um script “MemInfo.sh” — que efetua o “cálculo novo” — e salva o resultado em um arquivo “MemInfo.txt”:

MEM_TOTAL=$(awk '/MemTotal/ { printf $2 }' /proc/meminfo); \
MEM_AVAIL=$(awk '/MemAvailable/ { printf $2 }' /proc/meminfo); \
MEM_USED_KILO="$(($MEM_TOTAL-$MEM_AVAIL))"; \
echo "$(($MEM_USED_KILO/1024))" MiB > MemInfo.txt

O ciclo de 10 segundos do “Conky2” evita oscilações contínuas — de modo que o gnome-screenshot ou o KDE Spectacle não capturem um valor já afetado por seu próprio acionamento (+ 25 ~ 40 MiB durante uns 25 segundos).

Em TXT

Também criei um script “RAM.sh” — que salva essas informações em um arquivo “RAM_00-Distro.txt”, 10 minutos após o boot. — Para registrá-las, basta reiniciar o computador e ir tomar um café:

echo "------------------------------------------------------------------"     >  RAM_02-Arch.txt
date                                                                          >> RAM_02-Arch.txt
echo "--------------------   uptime   ----------------------------------"     >> RAM_02-Arch.txt
uptime -p                                                                     >> RAM_02-Arch.txt
uptime -s                                                                     >> RAM_02-Arch.txt
echo "-----------------   MemTotal - MemAvailable   --------------------"     >> RAM_02-Arch.txt
MEM_TOTAL=$(awk '/MemTotal/ { printf $2 }' /proc/meminfo);\
MEM_AVAIL=$(awk '/MemAvailable/ { printf $2 }' /proc/meminfo);\
MEM_USED_KILO="$(($MEM_TOTAL-$MEM_AVAIL))";\
MEM_USED_BYTES_X_1000="$(($MEM_USED_KILO*1000))";\
echo "$(($MEM_USED_KILO/1024))" MiB                                           >> RAM_02-Arch.txt
echo "$(($MEM_USED_BYTES_X_1000/1048576))" MiB, exactly                       >> RAM_02-Arch.txt
echo "--------------------    Conky   ----------------------------------"     >> RAM_02-Arch.txt
conky -c ~/.config/conky/conky3.conf
cat Conky.txt                                                                 >> RAM_02-Arch.txt
echo "---------------------   free   -----------------------------------"     >> RAM_02-Arch.txt
free -m                                                                       >> RAM_02-Arch.txt
echo "---------------------   top    -----------------------------------"     >> RAM_02-Arch.txt
top -E m -b -n 1 | grep buff                                                  >> RAM_02-Arch.txt
echo "--------------------- neofetch -----------------------------------"     >> RAM_02-Arch.txt
neofetch  --stdout | grep "Memory"                                            >> RAM_02-Arch.txt
echo "---------------------   htop   -----------------------------------"     >> RAM_02-Arch.txt
export TERM=xterm; echo q | htop | aha --line-fix | html2text | grep "/15"    >> RAM_02-Arch.txt
# export TERM=xterm; echo q | htop                                              >> RAM_02-Arch.txt
echo "---------------------   inxi   -----------------------------------"     >> RAM_02-Arch.txt
inxi -m                                                                       >> RAM_02-Arch.txt
echo "------------------- screenfetch ----------------------------------"     >> RAM_02-Arch.txt
screenfetch -n -N -E | grep "RAM"                                             >> RAM_02-Arch.txt
echo "------------------------------------------------------------------"     >> RAM_02-Arch.txt
date                                                                          >> RAM_02-Arch.txt
echo "------------------------------------------------------------------"     >> RAM_02-Arch.txt
echo '•' > done.txt

Acima - Para salvar em arquivo a variável mem do Conky, o script executa o Conky3 — apenas 1 vez (total_run_times = 1). — Encontrei essa dica de 2011 no Linux Questions e atualizei a sintaxe (out_to_x = false):

conky.config = {
 out_to_x = false,
 out_to_console = false,
 out_to_stderr = false,
 own_window = no,
 extra_newline = false,
 uppercase = no,
 overwrite_file = 'Conky.txt',
 no_buffers = yes,
 double_buffer = false,
 total_run_times = 1,
}
conky.text = [[
Conky (Mem)        ${mem}
]]

No final, o bash script cria um arquivo “done.txt” com um bullet “•”, que o Conky2 exibe à esquerda do indicador X11 / Wayland — e depois disso, já posso começar a usar a máquina:

Calculando o uso de RAM para monitorar as ferramentas

O bullet “•” permanece à esquerda do indicador X11 / Wayland por 3 minutos (até 13 minutos uptime) — quando é apagado por outro script: — “VERSIONS.sh”.

Este segundo script apenas adiciona ao arquivo “RAM_00-Distro.txt” as versões da distro, do Kernel, do init, do KDE e das ferramentas. — Em seguida, move o arquivo para uma pasta comum a todas as distros — e por fim, torna a esvaziar o arquivo “done.txt”, eliminando assim o bullet “•”:

echo '-------  Versions  -----------'             >> RAM_02-Arch.txt
echo '------------------------------'             >> RAM_02-Arch.txt
date                                              >> RAM_02-Arch.txt
echo '------------------------------'             >> RAM_02-Arch.txt
uname -n                                          >> RAM_02-Arch.txt
lsb_release -ds                                   >> RAM_02-Arch.txt
uname -sr                                         >> RAM_02-Arch.txt
strings /sbin/init | awk 'match($0, /(upstart|systemd|sysvinit|busybox|runit|openrc|S6|66-boot)/) { print substr($0, RSTART, RLENGTH);exit; }'\
                                                  >> RAM_02-Arch.txt
systemctl --version | grep systemd | cut -c 9-11  >> RAM_02-Arch.txt
#rc-service -V                                     >> RAM_02-Arch.txt
echo '------------------------------'             >> RAM_02-Arch.txt
plasmashell --version                             >> RAM_02-Arch.txt
neofetch  --de_version on --stdout | grep "DE:"   >> RAM_02-Arch.txt
kf5-config --version | grep 'Qt\|KDE'             >> RAM_02-Arch.txt
echo '------------------------------'             >> RAM_02-Arch.txt
konsole -v                                        >> RAM_02-Arch.txt
kate -v                                           >> RAM_02-Arch.txt
dolphin -v                                        >> RAM_02-Arch.txt
gwenview -v                                       >> RAM_02-Arch.txt
echo '------------------------------'             >> RAM_02-Arch.txt
gimp --version                                    >> RAM_02-Arch.txt
google-chrome-stable --version                    >> RAM_02-Arch.txt
libreoffice --version                             >> RAM_02-Arch.txt
echo '------------------------------'             >> RAM_02-Arch.txt
conky -v | grep compiled                          >> RAM_02-Arch.txt
free -V                                           >> RAM_02-Arch.txt
top -v | grep procps                              >> RAM_02-Arch.txt
neofetch --version                                >> RAM_02-Arch.txt
htop --version                                    >> RAM_02-Arch.txt
inxi -V | grep inxi                               >> RAM_02-Arch.txt
screenfetch -V | grep Version                     >> RAM_02-Arch.txt
echo '------------------------------'             >> RAM_02-Arch.txt
date                                              >> RAM_02-Arch.txt
echo '------------------------------'             >> RAM_02-Arch.txt
mv RAM_02-Arch.txt /run/media/flavio/Warehouse/Byteria/Conky/Conky-RAM-New/
echo ' ' > done.txt

Uso um comando padronizado para detectar o software init — e outros comandos, “caso-a-caso”, para obter a versão de cada init. — Apenas no Void, ainda não descobri como exibir a versão do runit:

[PATH]/Conky/backup/2022-07-18

$ grep -R -A 2 sysname

openSUSE   ${sysname} ${kernel} ${alignr}\
           ${execi 600 echo $(strings /sbin/init | awk 'match($0, /(upstart|systemd|sysvinit|busybox|runit|openrc|S6|66-boot)/) { print substr($0, RSTART, RLENGTH);exit; }')} \
           ${execi 600 systemctl --version | grep systemd | cut -c 9-11}

Arch       ${sysname} ${kernel} ${alignr}\
           ${execi 600 echo $(strings /sbin/init | awk 'match($0, /(upstart|systemd|sysvinit|busybox|runit|openrc|S6|66-boot)/) { print substr($0, RSTART, RLENGTH);exit; }')} \
           ${execi 600 systemctl --version | grep systemd | cut -c 9-11}

Debian     ${sysname} ${kernel} ${alignr}\
           ${execi 600 echo $(strings /sbin/init | awk 'match($0, /(upstart|systemd|sysvinit|busybox|runit|openrc|S6|66-boot)/) { print substr($0, RSTART, RLENGTH);exit; }')} \
           ${execi 600 systemctl --version | grep systemd | cut -c 9-11}

Fedora     ${sysname} ${kernel} ${alignr}\
           ${execi 600 echo $(strings /sbin/init | awk 'match($0, /(upstart|systemd|sysvinit|busybox|runit|openrc|S6|66-boot)/) { print substr($0, RSTART, RLENGTH);exit; }')} \
           ${execi 600 systemctl --version | grep systemd | cut -c 9-11}

KDE Neon   ${sysname} ${kernel} ${alignr}\
           ${execi 600 echo $(strings /sbin/init | awk 'match($0, /(upstart|systemd|sysvinit|busybox|runit|openrc|S6|66-boot)/) { print substr($0, RSTART, RLENGTH);exit; }')} \
           ${execi 600 systemctl --version | grep systemd | cut -c 9-11}

PCLinuxOS  Kernel ${sysname} ${kernel} ${alignr}\
           ${execi 600 echo $(strings /sbin/init | awk 'match($0, /(upstart|systemd|sysvinit|busybox|runit|openrc|S6|66-boot)/) { print substr($0, RSTART, RLENGTH);exit; }')} \
           ${execi 600 strings /sbin/init | grep INIT_VERSION | cut -c 23-30}

Mageia     ${sysname} ${kernel} ${alignr}\
           ${execi 600 echo $(strings /sbin/init | awk 'match($0, /(upstart|systemd|sysvinit|busybox|runit|openrc|S6|66-boot)/) { print substr($0, RSTART, RLENGTH);exit; }')} \
           ${execi 600 systemctl --version | grep systemd | cut -c 9-11}

Slackware  ${sysname} ${kernel} ${alignr}\
           ${execi 600 echo $(strings /sbin/init | awk 'match($0, /(upstart|systemd|sysvinit|busybox|runit|openrc|S6|66-boot)/) { print substr($0, RSTART, RLENGTH);exit; }')} \
           ${execi 600 strings /sbin/init | grep INIT_VERSION | cut -c 23-30}

Void       ${sysname} ${kernel} ${alignr}\
           ${execi 600 echo $(strings /sbin/init | awk 'match($0, /(upstart|systemd|sysvinit|busybox|runit|openrc|S6|66-boot)/) { print substr($0, RSTART, RLENGTH);exit; }')}

Manjaro    ${sysname} ${kernel} ${alignr}\
           ${execi 600 echo $(strings /sbin/init | awk 'match($0, /(upstart|systemd|sysvinit|busybox|runit|openrc|S6|66-boot)/) { print substr($0, RSTART, RLENGTH);exit; }')} \
           ${execi 600 systemctl --version | grep systemd | cut -c 9-11}

Redcore    ${sysname} ${kernel} ${alignr}\
           ${execi 600 echo $(strings /sbin/init | awk 'match($0, /(upstart|systemd|sysvinit|busybox|runit|openrc|S6|66-boot)/) { print substr($0, RSTART, RLENGTH);exit; }')} \
           ${execi 600 rc-service -V | cut -c 21-26}

MX Linux   ${sysname} ${kernel}  ${alignr}\
           ${execi 600 echo $(strings /sbin/init | awk 'match($0, /(upstart|systemd|sysvinit|busybox|runit|openrc|S6|66-boot)/) { print substr($0, RSTART, RLENGTH);exit; }')} \
           ${execi 600 strings /sbin/init | grep INIT_VERSION | cut -c 23-30}

É comum eu atualizar algumas distros em 10 minutos, e reiniciar o computador antes da eliminação do bullet. — Para evitar que ele apareça em uma próxima sessão, ele é eliminado logo após um novo boot:

$ crontab -l
@reboot echo ' ' > done.txt
@reboot sleep 600; bash RAM.sh
@reboot sleep 780; bash VERSIONS.sh

Naturalmente, só 2 ou 3 vezes por ano eu me preocupo em esperar 13 minutos após o boot, com o computador “em repouso”, em 12 distros seguidas, para cumprir todos esses passos. — Isso exige mais de 3 horas — e não é frequente eu ver motivo para tanto trabalho.

Nos outros casos, os arquivos abandonados são sobrescritos, e não se acumulam.

Procurando o uso de Memória RAM do htop

Os arquivos “RAM_00-Distro.txt” ainda contêm muito lixo — em especial nas distros sem o aha ou o html2text, para o grep salvar uma linha enxuta do htop.

Extraindo e reunindo os dados de todas as distros

Além disso, era trabalhoso abrir 12 arquivos “RAM_00-Distro.txt”, um após outro, e garimpar cada informação — então, comecei a desenvolver um script “Summary.sh” — para extrair os dados relevantes e reuni-los em um “Summary.txt”:

###    -----------------------------------    ###
###    Extracts data from "RAM*.txt" files    ###
###    -----------------------------------    ###
echo '----------------------------------------'                              > Summary.txt
echo "   ${PWD##*/}"                                                        >> Summary.txt
echo '--------------- New Calc ---------------'                             >> Summary.txt
cat RAM*.txt | grep "MemTotal - MemAvailable" -A1 | grep MiB                >> Summary.txt
cat RAM*.txt | grep "MemTotal - MemAvailable" -A1 | grep MiB | wc --lines   >> Summary.txt
echo '--------------- Conky ---------------'                                >> Summary.txt
cat RAM*.txt | grep "Conky (Mem)"                                           >> Summary.txt
cat RAM*.txt | grep "Conky (Mem)" | wc --lines                              >> Summary.txt
echo '--------------- free ---------------'                                 >> Summary.txt
cat RAM*.txt | grep "shared" -A1                                            >> Summary.txt
cat RAM*.txt | grep "shared" -A1 | wc --lines                               >> Summary.txt
echo '       -------> 3 * 13 = 39 - 1 separador a menos'                    >> Summary.txt
echo '--------------- top ---------------'                                  >> Summary.txt
cat RAM*.txt | grep " top" -A1 | grep "buff/cache"                          >> Summary.txt
cat RAM*.txt | grep " top" -A1 | grep "buff/cache" | wc --lines             >> Summary.txt
echo '--------------- Neofetch ---------------'                             >> Summary.txt
cat RAM*.txt | grep "Memory: "                                              >> Summary.txt
cat RAM*.txt | grep "Memory: " | wc --lines                                 >> Summary.txt
echo '--------------- htop ---------------'                                 >> Summary.txt
grep -E -o ".{0,10}15.5G.{0,1}" RAM*txt                                     >> Summary.txt
grep -E -o ".{0,10}15.5G.{0,1}" RAM*txt | wc --lines                        >> Summary.txt
echo '--------------- inxi ---------------'                                 >> Summary.txt
cat RAM*.txt | grep " inxi " -A2 | grep used                                >> Summary.txt
cat RAM*.txt | grep " inxi " -A2 | grep used | wc --lines                   >> Summary.txt
echo '--------------- screenFetch ---------------'                          >> Summary.txt
cat RAM*.txt | grep " screenfetch " -A1 | grep RAM                          >> Summary.txt
cat RAM*.txt | grep " screenfetch " -A1 | grep RAM | wc --lines             >> Summary.txt
echo '   09 ----- Void has not -----'                                       >> Summary.txt
echo '--------------- Versions ---------------'                             >> Summary.txt
echo '--------------- Conky ---------------'                                >> Summary.txt
cat RAM*.txt | grep "compiled"                                              >> Summary.txt
cat RAM*.txt | grep "compiled" | wc --lines                                 >> Summary.txt
echo '--------------- procps ---------------'                               >> Summary.txt
cat RAM*.txt | grep "free from"                                             >> Summary.txt
cat RAM*.txt | grep "free from" | wc --lines                                >> Summary.txt
echo '--------------- Neofetch ---------------'                             >> Summary.txt
cat RAM*.txt | grep "Neofetch "                                             >> Summary.txt
cat RAM*.txt | grep "Neofetch " | wc --lines                                >> Summary.txt
echo '--------------- htop ---------------'                                 >> Summary.txt
cat RAM*.txt | grep "htop 3"                                                >> Summary.txt
cat RAM*.txt | grep "htop 3" | wc --lines                                   >> Summary.txt
echo '--------------- inxi ---------------'                                 >> Summary.txt
cat RAM*.txt | grep "inxi 3"                                                >> Summary.txt
cat RAM*.txt | grep "inxi 3" | wc --lines                                   >> Summary.txt
echo '--------------- screenFetch ---------------'                          >> Summary.txt
cat RAM*.txt | grep "screenFetch"                                           >> Summary.txt
cat RAM*.txt | grep "screenFetch" | wc --lines                              >> Summary.txt
echo '   09 ----- Void has not -----'                                       >> Summary.txt
echo '-------------------------------------------'                          >> Summary.txt

Ao reunir os dados de cada ferramenta, aproveito para contar o número de linhas encontradas — para conferir se falta alguma coisa — e inserir um lembrete de que o Void, por exemplo, ainda está sem screenFetch.

Uso do “Modo de Seleção de Blocos” do Kate / KWrite

Ainda está muito longe de uma “automação total”, mas já facilita para organizar os números em colunas — e copiá-las para uma planilha — pelo “Modo de Seleção de Blocos” do Kate / KWrite.

Referências:

Aplicativos GUI

KSysguard

KSysguard indica menos do que o “cálculo muito antigo”

O nome genérico “Monitor do Sistema” tem induzido a muitos enganos e falsas comparações — pelo menos desde 2016, quando tive o KSysguard e o Gnome System Monitor lado a lado, em um Debian com vários ambientes.

Desde aquela época, verifiquei que o KSysguard indicava uso de Memória bem inferior ao indicado pelo Conky — ainda com o “cálculo antigo”.

Me parece que o KSysguard utiliza o “cálculo muito antigo” do free — e ainda “desconta” seu próprio uso de Memória. — Acontece que o free não “desconta” o peso do KSysguard, e por isso indica um número maior do que ele.

Acima - A simples abertura do KSysguard elevou o uso de Memória RAM de 865 MiB para 1046 MiB (+181 MiB), segundo o cálculo “novo” — ou de 428 MiB para 531 MiB (+103 MiB), segundo o “cálculo muito antigo” do free.

O valor de 0,48 GiB indicado pelo KSysguard equivale a 492 MiB — menos que os 531 MiB indicados pelo free (-39 MiB).

Plasma System Monitor

Plasma System Monitor utiliza o “cálculo novo”

Ao fechar o KSysguard, o uso de Memória RAM caiu para 962 MiB, segundo o “cálculo novo” — cerca de 100 MiB acima dos 865 MiB iniciais.

Portanto, quando abri o Plasma System Monitor, já parti de um patamar um pouco mais elevado.

Acima - O novo Plasma System Monitor indicava uso de 1,1 GiB de Memória RAM — valor exato dos 1128 MiB indicados pelo “cálculo novo” (1,1 GiB).

Gnome System Monitor

Gnome System Monitor utiliza o “cálculo novo”

Ao fechar o Plasma System Monitor, o uso de Memória RAM também não volta ao que era logo no início da sessão. — Mesmo assim, o Gnome System Monitor parece “pesar” menos do que as 2 ferramentas do KDE.

Acima - O Gnome System Monitor indica uso de 1,0 GiB — valor muito próximo aos 1000 MiB indicados pelo “cálculo novo” (0,98 GiB).

Um minuto após fechar o Gnome System Monitor, o uso de Memória RAM baixou para 974 MiB, segundo o “cálculo novo” — cerca de 110 MiB acima dos 865 MiB logo após a inicialização. — Este foi o “saldo” de abrir e fechar as 3 ferramentas GUI, uma após outra, pois o sistema guarda parte desses aplicativos em Memória Cache, para evitar nova leitura de disco e abrir mais rápido da próxima vez.

Terminais

O “peso” de qualquer aplicação GUI sempre interfere naquilo que pretende medir — uso de Memória RAM, uso de CPU etc. — por isso desde 2016 optei por usar o Conky, que tem baixíssimo uso de recursos.

Mesmo a abertura de um emulador de Terminal já altera significativamente o uso de Memória RAM. — Além disso, diferentes DEs usam emuladores de Terminal mais “leves” ou mais “pesados” — o que também torna enganosa a comparação entre diferentes distros e DEs, mesmo quando pensamos estar usando “apenas uma ferramenta CLI”, como free, htop, Neofetch etc.

Para realmente usar “só a ferramenta CLI”, deixe o DE em repouso — e use a ferramenta CLI em um “terminal tty” — tty2, por exemplo.

_______________________
• Publicado em Outubro 2020 e atualizado até Junho 2024 (histórico).

— … ≠ • ≠ … —

Ferramentas &tc.

Grub enlouquecido com 12 distros em multiboot

Remanejamento de sistemas Linux ao reparticionar discos

Backup total e limpeza das partições de trabalho

Migrando sistemas Linux para disco rígido de 1 Terabyte

Ensaio de avaliação com luckyBackup e Unison

Particionamento de Drive SSD para vários Linux

Slackware by Alien - install, config

noreply@blogger.com (Mboaba) — Wed, 30 Sep 2020 14:48:00 +0000

Slackware by Alien em sessão Plasma KDE

Está é a terceira ou quarta vez que reinstalo o Slackware by Alien Bob; — as primeiras vezes, por tê-lo escangalhado além das minhas possibilidades de consertá-lo; — agora, por simples migração para um novo hardware (e vim adiando, desde Janeiro).

Mais do que nunca, isto não é um “tutorial”. — Só um registro do que fiz, — tateando e cometendo muitos erros.

Pós-instalação

Correção do Grub (externo) para carregar o Slackware

O Grub do openSUSE e do Mageia produziu entradas para “vmlinuz-generic-5.4.66”, e o boot se paralisou em “Kernel panic”. — Nesse primeiro momento, bastou corrigir manualmente para “vmlinuz-huge-5.4.66”, para conseguir carregar o Slackware.

Desabilitando Os-Prober e gerando o Grub

Com isso, pude gerar o arquivo /boot/grub/grub.cfg do próprio Slackware, — e depois disso, o Grub das outras distros já pode ler nele o parâmetro correto:

# grub-install /dev/sda1
Installing for x86_64-efi platform.
Installation finished. No error reported.

# date; grub-mkconfig -o /boot/grub/grub.cfg; date
Sat Sep 26 14:38:40 -03 2020
Generating grub configuration file ...
Found linux image: /boot/vmlinuz-huge-5.4.66
Found initrd image: /boot/initrd.gz
Found linux image: /boot/vmlinuz-huge
Found initrd image: /boot/initrd.gz
Found linux image: /boot/vmlinuz-generic-5.4.66
Found initrd image: /boot/initrd.gz
Found linux image: /boot/vmlinuz-generic
Found initrd image: /boot/initrd.gz
done
Sat Sep 26 14:38:44 -03 2020

Pastas das distros Linux na partição EFI

Note que, para isso, não precisava instalar a “chamada” na partição EFI. — Fiz isso, só para “ver” o que seria gravado lá, pois varia muito de uma distro para outra. — Mas sempre pode ser útil, a qualquer momento.

De qualquer modo, o Grub do Slackware também não precisava perder tempo detectando outras distros, — e primeiro acrescentei uma linha em /etc/default/grub:

GRUB_DISABLE_OS_PROBER=true

Essa edição foi feita no editor interno do mc (Midnight-Commander), logado como root.

Só 10 minutos depois, lembrei de datar os comandos:

$ history
    1                       su
    2                       echo 'export HISTTIMEFORMAT="%F_%H-%M-%S "' >> ~/.bashrc
    3  2020-09-26_14-58-33  history

# history
    1                       cd /usr/lib64/vlc
    2                       find . -name "plugins*.dat" -exec rm -f {} \;
    3                       echo "Generating VLC plugins cache data..."
    4                       DISPLAY="" ./vlc-cache-gen /usr/lib64/vlc/plugins
    5                       grub-install /dev/sda1
    6                       mc
    7                       mc
    8                       date; grub-mkconfig -o /boot/grub/grub.cfg; date
    9                       mc
   10                       mc
   11                       echo 'export HISTTIMEFORMAT="%F_%H-%M-%S "' >> ~/.bashrc
   12  2020-09-26_14-58-44  history

Antes desse momento, eu havia executado (como root) apenas alguns comandos relacionados ao VLC, — talvez sugeridos pelo próprio Slackware, ao abrir o Konsole. — Não fiz anotações sobre isso, nem capturas de tela, e só posso imaginar o objetivo desses comandos.

Opção de montagem em serviços de segundo plano

A montagem automática de partições adicionais me tomou mais de 1 hora, e saiu dos trilhos que eu me havia acostumado a seguir.

13:49 - Ao desativar serviços em segundo plano que não uso, não vi essa opção, — que por sinal, eu nunca vi em nenhuma outra distro, mesmo as que já usam KDE mais recente. — Não vi, não ativei, e talvez esteja ligada ao problema que enfrentei em seguida.

14:05 - Ativei a montagem automática de “dispositivos removíveis” (que não são do sistema) no KDE System settings. — Isso nunca funcionou nas instalações anteriores do Slackware, — mas também nunca atrapalhou.

15:24 - Nova sessão (reiniciei, ou só logout / login?), naturalmente sem montagem das partições adicionais.

15:33 - Colei no /etc/fstab um conjunto de linhas que sempre funcionou para a montagem das partições adicionais, — tanto no Slackware, quando no Debian, LMDE, MX Linux...

15:36 - ... mas ao reiniciar o computador, as partições adicionais não foram montadas.

15:52 - Tentativas de montagem manual retornaram o aviso de que não existiam os pontos de montagem, — coisa que nunca foi problema, nas instalações anteriores.

15:57 - Criei manualmente um ponto de montagem, para teste, — mas não reiniciei, portanto não houve oportunidade de verificar se ia funcionar ou não. — Me limitei a tentar a montagem daquela única partição, pelo Dolphin, e como foi pedida senha, concluí que não resolveu.

xxx

xxx

— … ≠ • ≠ … —

Without-SystemD

PC desktop UEFI / GPT

Ferramentas &tc.

Grub enlouquecido com 12 distros em multiboot

Não-debians

KDE Neon upgrade 20.04 Focal Fossa

noreply@blogger.com (Mboaba) — Sat, 15 Aug 2020 19:54:00 +0000

KDE Neon após upgrade para 20.04 Focal Fossa

O upgrade do KDE Neon, da base Ubuntu 18.04 Bionic para 20.04 Focal Fossa, transcorreu sem qualquer problema, — e não introduziu nenhuma alteração no Plasma KDE, nem no Kernel. — Sob esses aspectos, é como se o KDE Neon permanecesse o mesmo de 2 semanas atrás:

2020-08-02                                                  2020-08-15

      Operating System: KDE neon 5.19                             Operating System: KDE neon 5.19
    KDE Plasma Version: 5.19.4                                  KDE Plasma Version: 5.19.4
KDE Frameworks Version: 5.72.0                              KDE Frameworks Version: 5.72.0
            Qt Version: 5.14.2                                          Qt Version: 5.14.2
        Kernel Version: 5.4.0-42-generic                            Kernel Version: 5.4.0-42-generic
...                                                         ...
    Graphics Processor: Mesa DRI Intel® UHD Graphics 630        Graphics Processor: Mesa Intel® UHD Graphics 630

 konsole 20.04.3                                             konsole 20.04.3
 dolphin 20.04.3                                             dolphin 20.04.3
    kate 20.04.3                                                kate 20.04.3
gwenview 20.04.3                                            gwenview 20.04.3

O Chromium (.deb) não foi removido, nem substituído pela versão .snap2. — Apenas, agora o apt / Synaptic o classifica como “obsoleto”, por não mais encontrá-lo nos repositórios. — No momento, tenho algum prazo para decidir o que vou fazer.

O repositório do GoogleEarth foi automaticamente desabilitado, ao iniciar o upgrade, — e bastou habilitá-lo de novo, depois. — O GoogleEarth continua funcionando normalmente.

Ainda não verifiquei o que mudou no Wine, — mas minha velha versão do Dreamweaver também continua funcionando como antes.

corona-cli finalmente encontra as dependências requeridas

Uma boa nova é que, agora, o corona-cli funciona, — o que antes não era possível.

O Gimp passou da versão 2.8 para 2.10, — mas para isso eu já estava preparado, desde o final de 2018. — Conforme o esperado, algumas configurações foram preservadas, e outras tive de refazer.

Upgrade

Verificando atualizações, no início da sessão do KDE Neon

Um requisito elementar, em distribuições Linux de versão fixa, é que a instalação deve estar atualizada, antes de se iniciar o upgrade para uma nova versão.

Em situações normais, verifico manualmente as atualizações pelo apt, depois aplico pelo Synaptic, — e é claro que eu já tinha feito isso, mais cedo. — Apenas tornei a verificar, por via das dúvidas, antes de iniciar o upgrade.

Última verificação de atualizações, antes de iniciar o upgrade do KDE Neon

Mas o site oficial do KDE Neon tem recomendações próprias, — tais como a de usar o Rosa Writer para “queimar” suas imagens ISO em Pendrive, — e a de usar o PackageKit (pkcon) para verificar e aplicar as atualizações.

Nunca encontrei uma explicação para essas idiossincrasias, — e nunca vi o pkcon discordar do apt / Synaptic, — afinal o PackageKit (tal como o Synaptic) é só uma interface amigável, que nas distros .deb usa o apt.

Em honra a esse ritual não-explicado, de bom grado executei um pkcon após o apt, — e é óbvio que ele não encontrou mais nada para atualizar.

Em seguida iniciei a execução do script, — que salva todas as saídas dos comandos em um arquivo “typescript”, na pasta do usuário:

$ history
...
  283  2020-08-13_20-49-06 date && sudo apt update && date
  284  2020-08-13_20-49-30 sudo pkcon refresh
  285  2020-08-13_20-52-27 script

Esse arquivo ~/typescript salvou nada menos que 62.972 linhas, — que resumo abaixo, com “...” para indicar as partes suprimidas, por serem muito extensas, ou repetitivas:

Script started on 2020-08-13 20:52:27-0300
...
$ date && sudo do-release-upgrade && date
Thu 13 Aug 20:52:32 -03 2020
...
Checking for a new Ubuntu release

0% [Working]
0% [Connecting to archive.neon.kde.org]
...
authenticate 'focal.tar.gz' against 'focal.tar.gz.gpg'
extracting 'focal.tar.gz'
...

Updating repository information

Third party sources disabled

Some third party entries in your sources.list were disabled. You can
re-enable them after the upgrade with the 'software-properties' tool
or your package manager.

To continue please press [ENTER]
...

100% [Working]                    218 kB/s 0s
Fetched 52.4 MB in 6s (218 kB/s)

Checking package manager
...

Reading state information... Done

Calculating the changes
...

Do you want to start the upgrade?

31 packages are going to be removed. 641 new packages are going to be
installed. 2132 packages are going to be upgraded.

You have to download a total of 2118 M. This download should take
about 1 hour 2 minutes with your connection.

Installing the upgrade can take several hours. Once the download has
finished, the process cannot be cancelled.

 Continue [yN]  Details [d] y

Fetching
...
0% [Working]
...
100% [Working]                     1329 kB/s 0s

Fetched 2118 MB in 6s (1329 kB/s)

Upgrading

Fetched 0 B in 0s (0 B/s)
  MarkInstall libc6:amd64 < 2.27-3ubuntu1.2 -> 2.31-0ubuntu9 @ii umU Ib > FU=1
  Installing libgcc-s1 as Depends of libc6
    MarkInstall libgcc-s1:amd64 < none -> 10-20200411-0ubuntu1 @un uN Ib > FU=0
    Installing gcc-10-base as Depends of libgcc-s1
      MarkInstall gcc-10-base:amd64 < none -> 10-20200411-0ubuntu1 @un uN > FU=0
  Installing libcrypt1 as Depends of libc6
    MarkInstall libcrypt1:amd64 < none -> 1:4.4.10-10ubuntu4 @un uN Ib > FU=0
      MarkInstall libc6:i386 < 2.27-3ubuntu1.2 -> 2.31-0ubuntu9 @ii umU Ib > FU=0
      Installing libgcc-s1 as Depends of libc6
        MarkInstall libgcc-s1:i386 < none -> 10-20200411-0ubuntu1 @un uN Ib > FU=0
        Installing gcc-10-base as Depends of libgcc-s1
          MarkInstall gcc-10-base:i386 < none -> 10-20200411-0ubuntu1 @un uN > FU=0
      Installing libcrypt1 as Depends of libc6
        MarkInstall libcrypt1:i386 < none -> 1:4.4.10-10ubuntu4 @un uN > FU=0
        MarkInstall locales:amd64 < 2.27-3ubuntu1.2 -> 2.31-0ubuntu9 @ii umU Ib > FU=0
        Installing libc-bin as Depends of locales
          MarkInstall libc-bin:amd64 < 2.27-3ubuntu1.2 -> 2.31-0ubuntu9 @ii umU > FU=0
      new important dependency: libidn2-0:i386
      Installing libidn2-0 as Recommends of libc6
        MarkInstall libidn2-0:i386 < 2.0.4-1.1ubuntu0.2 -> 2.2.0-2 @ii umU Ib > FU=0
          MarkInstall libidn2-0:amd64 < 2.0.4-1.1ubuntu0.2 -> 2.2.0-2 @ii umU > FU=0
Starting pkgProblemResolver with broken count: 1
Starting 2 pkgProblemResolver with broken count: 1
Investigating (0) libc6-dev:amd64 < 2.27-3ubuntu1.2 -> 2.31-0ubuntu9 @ii umU Ib >
Broken libc6-dev:amd64 Depends on libcrypt-dev:amd64 < none | 1:4.4.10-10ubuntu4 @un uH >
  Considering libcrypt-dev:amd64 1 as a solution to libc6-dev:amd64 11
  MarkKeep libc6-dev:amd64 < 2.27-3ubuntu1.2 -> 2.31-0ubuntu9 @ii umU Ib > FU=0
  Re-Instated manpages-dev:amd64
  Re-Instated libcrypt-dev:amd64
  Re-Instated libc6-dev:amd64
Done

Upgrading

Fetched 0 B in 0s (0 B/s)
Preconfiguring packages ...
...
Selecting previously unselected package gcc-10-base:amd64.
(Reading database ...
(Reading database ... 5%
...
(Reading database ... 100%
(Reading database ... 240874 files and directories currently installed.)
Preparing to unpack .../gcc-10-base_10-20200411-0ubuntu1_amd64.deb ...
...
...
Preparing to unpack .../948-usb-modeswitch-data_20191128-3_all.deb ...
Unpacking usb-modeswitch-data (20191128-3) over (20170806-2) ...
Preparing to unpack .../949-youtube-dl_2020.03.24-1_all.deb ...
Unpacking youtube-dl (2020.03.24-1) over (2018.03.14-1ubuntu18.04.1) ...
Setting up libgme0:amd64 (0.6.2-1build1) ...
Setting up libmono-system-servicemodel-internals0.0-cil (6.8.0.105+dfsg-2) ...
Setting up libkf5codecs-data (5.72.0-0xneon+20.04+focal+build3) ...
Setting up libssh-gcrypt-4:amd64 (0.9.3-2ubuntu2.1) ...
Setting up libpwquality-common (1.4.2-1build1) ...
Installing new version of config file /etc/security/pwquality.conf ...
Setting up kdeplasma-addons-data (4:5.19.4-0xneon+20.04+focal+build7) ...
Setting up memtest86+ (5.01-3.1ubuntu1) ...
Sourcing file `/etc/default/grub'
Sourcing file `/etc/default/grub.d/99_breeze-grub.cfg'
Generating grub configuration file ...
Found theme: /boot/grub/themes/breeze/theme.txt
Found linux image: /boot/vmlinuz-5.4.0-42-generic
Found initrd image: /boot/initrd.img-5.4.0-42-generic
Found linux image: /boot/vmlinuz-5.3.0-62-generic
Found initrd image: /boot/initrd.img-5.3.0-62-generic
Adding boot menu entry for EFI firmware configuration
done
Setting up arj (3.10.22-23) ...
Setting up cpio (2.13+dfsg-2) ...
Setting up libavc1394-0:amd64 (0.5.4-5) ...
Setting up powermgmt-base (1.36) ...
...
...
Setting up kwin-wayland (4:5.19.4-0xneon+20.04+focal+build7) ...
Setcap worked for /usr/bin/kwin_wayland!
Setting up plasma-workspace-wayland (4:5.19.4-0xneon+20.04+focal+build6) ...
Setting up kinfocenter (4:5.19.4-0xneon+20.04+focal+build7) ...
Setting up konq-plugins (4:20.04.3-0xneon+20.04+focal+build4) ...
Setting up sddm-theme-breeze (4:5.19.4-0xneon+20.04+focal+build6) ...
Setting up plasma-desktop (4:5.19.4-0xneon+20.04+focal+build6) ...
Setting up neon-desktop (4+p20.04+git20200803.1619) ...
Processing triggers for install-info (6.7.0.dfsg.2-5) ...
Processing triggers for hicolor-icon-theme (0.17-2) ...
Processing triggers for libc-bin (2.31-0ubuntu9) ...
Processing triggers for systemd (245.4-4ubuntu3.2) ...
Processing triggers for ureadahead (0.100.0-21) ...
ureadahead will be reprofiled on next reboot
Processing triggers for ca-certificates (20190110ubuntu1.1) ...
Updating certificates in /etc/ssl/certs...
0 added, 0 removed; done.
Running hooks in /etc/ca-certificates/update.d...

done.
Updating Mono key store
Mono Certificate Store Sync - version 6.8.0.105
Populate Mono certificate store from a concatenated list of certificates.
Copyright 2002, 2003 Motus Technologies. Copyright 2004-2008 Novell. BSD licensed.

Importing into legacy system store:
I already trust 135, your new list has 127
6 previously trusted certificates were removed.
Certificate removed: C=TR, L=Ankara, O=TÜRKTRUST Bilgi İletişim ve Bilişim Güvenliği Hizmetleri A.Ş., CN=TÜRKTRUST Elektronik Sertifika Hizmet Sağlayıcısı H5
Certificate removed: C=SE, O=AddTrust AB, OU=AddTrust External TTP Network, CN=AddTrust External CA Root
Certificate removed: C=US, O=VISA, OU=Visa International Service Association, CN=Visa eCommerce Root
Certificate removed: C=FR, O=Certplus, CN=Certplus Root CA G1
Certificate removed: C=FR, O=OpenTrust, CN=OpenTrust Root CA G2
Certificate removed: C=FR, O=OpenTrust, CN=OpenTrust Root CA G1
Import process completed.

Importing into BTLS system store:
I already trust 0, your new list has 127
Certificate added: ...
...
127 new root certificates were added to your trust store.
Import process completed.
Done
done.
Setting up mono-devel (6.8.0.105+dfsg-2) ...
...
Processing triggers for linux-image-5.4.0-42-generic (5.4.0-42.46) ...
/etc/kernel/postinst.d/initramfs-tools:
update-initramfs: Generating /boot/initrd.img-5.4.0-42-generic
I: The initramfs will attempt to resume from /dev/sdb14
I: (UUID=2ae5ec7d-42bd-4d6b-9597-7473984c75fe)
I: Set the RESUME variable to override this.
/etc/kernel/postinst.d/zz-update-grub:
Sourcing file `/etc/default/grub'
Sourcing file `/etc/default/grub.d/99_breeze-grub.cfg'
Sourcing file `/etc/default/grub.d/init-select.cfg'
Generating grub configuration file ...
Found theme: /boot/grub/themes/breeze/theme.txt
Found linux image: /boot/vmlinuz-5.4.0-42-generic
Found initrd image: /boot/initrd.img-5.4.0-42-generic
Found linux image: /boot/vmlinuz-5.3.0-62-generic
Found initrd image: /boot/initrd.img-5.3.0-62-generic
Adding boot menu entry for UEFI Firmware Settings
done
Processing triggers for dictionaries-common (1.28.1) ...
aspell-autobuildhash: processing: en [en-common].
...
aspell-autobuildhash: processing: pt_BR [pt_BR].
Processing triggers for dbus (1.12.16-2ubuntu2.1) ...
Processing triggers for libvlc-bin:amd64 (3.0.9.2-1) ...
Processing triggers for initramfs-tools (0.136ubuntu6.2) ...
update-initramfs: Generating /boot/initrd.img-5.4.0-42-generic
I: The initramfs will attempt to resume from /dev/sdb14
I: (UUID=2ae5ec7d-42bd-4d6b-9597-7473984c75fe)
I: Set the RESUME variable to override this.
Processing triggers for libgdk-pixbuf2.0-0:amd64 (2.40.0+dfsg-3) ...
Processing triggers for libgdk-pixbuf2.0-0:i386 (2.40.0+dfsg-3) ...
Processing triggers for wine (5.0-3ubuntu1) ...

Reading package lists... 0%
...
Reading package lists... 97%

Reading package lists... Done

Building dependency tree... 0%
...
Building dependency tree... 50%

Building dependency tree

Reading state information... 0%
...
Reading state information... Done

Searching for obsolete software

Reading state information... 0%
...
Reading state information... 99%

Reading state information... Done

Remove obsolete packages?

296 packages are going to be removed.

Removing the packages can take several hours.

 Continue [yN]  Details [d] d

Remove: diffuse dolphin4 komparator libkonqsidebarplugin4a xxdiff

Remove (was auto installed) command-not-found-data fonts-noto
  fonts-noto-cjk-extra fonts-noto-ui-extra fonts-noto-unhinted
  freepats fwupdate gcc-8-base:i386 gconf-service
  gconf-service-backend gconf2-common iputils-arping kde-runtime
  kde-runtime-data kdelibs-bin kdelibs5-data kdelibs5-plugins
...
  libreoffice-avmedia-backend-gstreamer libreoffice-librelogo
  libreoffice-ogltrans libreoffice-sdbc-hsqldb
...
  linux-headers-5.3.0-62 linux-headers-5.3.0-62-generic
  linux-headers-generic linux-headers-generic-hwe-18.04
  linux-hwe-5.4-headers-5.4.0-42 linux-image-5.3.0-62-generic
  linux-image-generic-hwe-18.04 linux-modules-5.3.0-62-generic
  linux-modules-extra-5.3.0-62-generic mlocate mono-jay
...
  python-webencodings python-zipp python3.6 python3.6-minimal qdbus
  qpdf qt-at-spi qtcore4-l10n qtdeclarative5-qtquick2-plugin
  rarian-compat ruby-did-you-mean ruby2.5 sextractor ureadahead
  xwayland-hwe-18.04

Continue [yN]  Details [d] y

Fetched 0 B in 0s (0 B/s)
(Reading database ...
(Reading database ... 5%
...
(Reading database ... 100%
(Reading database ... 287037 files and directories currently installed.)
Removing command-not-found-data (18.04.5) ...
Removing diffuse (0.4.8-3) ...
Removing dolphin4 (4:16.04.3-0ubuntu1) ...
...
Removing linux-image-5.3.0-62-generic (5.3.0-62.56~18.04.1) ...
I: /boot/vmlinuz.old is now a symlink to vmlinuz-5.4.0-42-generic
I: /boot/initrd.img.old is now a symlink to initrd.img-5.4.0-42-generic
/etc/kernel/postrm.d/initramfs-tools:
update-initramfs: Deleting /boot/initrd.img-5.3.0-62-generic
/etc/kernel/postrm.d/zz-update-grub:
Sourcing file `/etc/default/grub'
Sourcing file `/etc/default/grub.d/99_breeze-grub.cfg'
Sourcing file `/etc/default/grub.d/init-select.cfg'
Generating grub configuration file ...
Found theme: /boot/grub/themes/breeze/theme.txt
Found linux image: /boot/vmlinuz-5.4.0-42-generic
Found initrd image: /boot/initrd.img-5.4.0-42-generic
Adding boot menu entry for UEFI Firmware Settings
done
Removing linux-image-generic-hwe-18.04 (5.4.0.42.46) ...
Removing linux-modules-5.3.0-62-generic (5.3.0-62.56~18.04.1) ...
Removing mlocate (0.26-3ubuntu3) ...
...
Removing libntrack0 (016-1.3) ...
Removing ntrack-module-libnl-0 (016-1.3) ...
Processing triggers for desktop-file-utils (0.24-1ubuntu3) ...
Processing triggers for mime-support (3.64ubuntu1) ...
Processing triggers for hicolor-icon-theme (0.17-2) ...
Processing triggers for cups (2.3.1-9ubuntu1.1) ...
Processing triggers for libc-bin (2.31-0ubuntu9) ...
Processing triggers for man-db (2.9.1-1) ...
Processing triggers for libreoffice-common (1:6.4.4-0ubuntu0.20.04.1) ...
Processing triggers for dbus (1.12.16-2ubuntu2.1) ...
Processing triggers for shared-mime-info (1.15-1) ...
Processing triggers for sgml-base (1.29.1) ...
Processing triggers for fontconfig (2.13.1-2ubuntu3) ...
dpkg: warning: package not in status nor available database at line 1: command-not-found-data:amd64
dpkg: warning: package not in status nor available database at line 3: dolphin4:amd64
...
dpkg: warning: package not in status nor available database at line 295: xwayland-hwe-18.04:amd64
dpkg: warning: package not in status nor available database at line 296: xxdiff:amd64
dpkg: warning: found unknown packages; this might mean the available database
is outdated, and needs to be updated through a frontend method;
please see the FAQ 
(Reading database ...
(Reading database ... 5%
...
(Reading database ... 100%
(Reading database ... 220343 files and directories currently installed.)
Purging configuration files for linux-image-5.3.0-62-generic (5.3.0-62.56~18.04.1) ...
...
Purging configuration files for kde-runtime (4:17.08.3-0ubuntu1) ...
Processing triggers for dbus (1.12.16-2ubuntu2.1) ...

System upgrade is complete.

Restart required

To complete the upgrade, a system restart is required.
If you select 'y' the system will be restarted.

Continue [yN] n
Thu 13 Aug 23:31:19 -03 2020

$ exit

Script done on 2020-08-13 23:31:48-0300

Note que eu mantenho desabilitada a detecção de outras distros (os-probe), — por isso as sucessivas atualizações do Grub detectam apenas as versões de Kernel do próprio KDE Neon.

Teclar “d” para detalhar os arquivos que serão instalados, atualizados, removidos

Ao final de alguns minutos, fui informado de que o upgrade do KDE Neon implicaria em remover 31 pacotes (na verdade, foram 296), instalar 641 pacotes novos, atualizar 2.132 pacotes, — download total de uns 2 GiB, — e demoraria cerca de 1 hora, a julgar pela velocidade da conexão até aquele momento.

Infelizmente, eu tinha esquecido de uma precaução básica: — Desligar o Modem e tornar a ligar, após alguns minutos, para melhorar a conexão, que vem decaindo há alguns meses. — Um teste tardio, pelo speedtest-cli, mostrou que naquele momento eu não podia contar com mais do que 50 Mbit/s, do total de 200 “megas” contratados (26,3 MiB/s).

Mas isso, até o PTT / IX mais “próximo”, — pois ainda ia depender da velocidade dos repositórios no Brasil (br.archive.ubuntu) e no exterior (archive.neon.kde, security.ubuntu), assim como das velocidades encontradas no caminho entre meu provedor e os repositórios. — Na prática, o download começou com uma média de 3,7 MiB/s (máximo 5,3 MiB/s), para os pacotes do repositório do KDE Neon; mas logo decaiu para uma faixa de 100 a 500 KiB/s, para os pacotes do repositório Ubuntu no Brasil; e o processo todo acabou demorando mais de 2h 30min (20:52 ~ 23:31).

Capturas de tela falhadas, na fase final do upgrade do KDE Neon

A navegação no Chromium, a música local no VLC, o monitoramento pelo Conky e quase tudo mais continuou funcionando normalmente, durante todo esse tempo. — Apenas a Captura de tela (shortcut PrtScn + gnome-screenshot) deixou de funcionar por alguns minutos, entre 23:00 e 23:20; e o Dolphin e o Gwenview (abertos desde o início) não recuperaram o acesso às pastas, depois disso; mas o Kate continuou salvando as anotações, até o final.

xxxx

Para uma lista dos 296 pacotes removidos:

Pacotes removidos

xxxx

— … ≠ • ≠ … —

PC desktop UEFI / GPT

Ferramentas &tc.

Grub enlouquecido com 12 distros em multiboot

Debian's

MX Linux 19.2 KDE beta 2

noreply@blogger.com (Mboaba) — Fri, 24 Jul 2020 03:57:00 +0000

MX Linux 19.2 KDE beta 2 •

Me interessei pelo MX Linux (e pelo antiX) há uns 2 anos, — por ser uma distro sem SystemD.

É também um Debian altamente configurado, por ferramentas próprias (MX Tools, MX Tweaks), — e em 2018 isso me dificultou substituir o Xfce pelo KDE. — Acho que eu devia ter tentado a substituição, antes de mexer demais naquelas configurações.

O anúncio do MX Linux 19.2 KDE beta 2 para teste voltou a me animar. — KDE pronto para usar, harmonizado com as configurações da distro. — Baixei, instalei, gostei, e me conciliei com o uso de um KDE “menos recente”. Está ótimo.

Isto não é um “tutorial”, — só anotações do que realmente fiz, — inclusive coisas não-recomendáveis, e provavelmente alguns erros.

Índice

ISO download, sha256sum, K3b
Sessão Live
MX Installer
Pós-instalação
MX Tweaks
Gerenciador de repositórios
Night colour vs. Redshift
Ícone do Menu
Pré-visualizações no Dolphin
Breeze dark no Synaptic, GParted, Disk Manager
Montagem de partições por udisks2 vs. fstab
Menu: Favoritos e Recentes
KDE antigo e outros incômodos
Init
Referências (2018)
Wallpapers

ISO download, sha256sum, K3b

Caminho indireto para a ISO do MX-19.2 KDE Beta 2

O MX-19.2 KDE Beta 2 foi anunciado em 17 Julho 2020, e será a primeira imagem ISO com KDE da comunidade MX (Mepis + antiX), desde a interrupção do projeto Mepis em 2013.

O anúncio incluiu links para download direto, para o Tópico de feedback do MX-19.2 KDE Beta 2 no Forum MX Linux, e para o Bugzilla da distro.

Fui à página geral de downloads do MX Linux no Source Forge, no dia seguinte, e acabei por encontrar a ISO KDE na pasta Testing. — Eu estava com sorte, e fiz o download em 86 segundos, o que equivale a 23,1 MiB/s, ou 185 Mbps, quase no limite da minha conexão de 200 Mbps. — Já tinham sido feitos 1.122 downloads, em apenas 24 horas, mais ou menos.

Verificação da imagem ISO MX Linux 19.2 KDE beta 2 e “queima” em DVD pelo K3b

No dia 22, fiz a verificação sha256sum e “queimei” em DVD, para guardar.

Sessão Live

Menu de inicialização do Live MX Linux 19.2 KDE beta 2

O Menu de inicialização do Live DVD já carregou com a segunda opção pré-selecionada, — “Inicialização personalizada (menus de texto)”, que percorre 6 submenus: — Idioma, tamanho das letras, Fuso horário, Relógio do sistema, carregamento da ISO para a Memória RAM, tipos de Persistência da sessão Live etc.

Em 2018, estes submenus podiam ser acessados, na tela inicial, pelas teclas F2 a F7 (detalhe à esquerda), o que permitia percorrê-los livremente, em qualquer ordem — enquanto a tecla F1 abria uma Ajuda bastante explicativa, com várias páginas.

Antes de continuar, fotografei as “Opções avançadas” (detalhe à direita), — e com Esc voltei ao Menu principal, para prosseguir.

Opções gerais e de persistência no Menu do Live MX Linux 19.2 KDE beta 2

As opções de “Inicialização personalizada (menus de texto)” merecem bastante leitura prévia, pelo grande número de recursos que oferecem, — a começar por detalhadas alternativas de Persistência em sessões Live.

Eu não pretendia explorar nenhuma dessas opções, no momento. — Me limitei a fotografar e teclar Enter, em todos os submenus, para aceitar os padrões. — Só mais tarde, já na sessão Live, editei as opções de Layout de teclado, Regionalização (Locale), Fuso horário (Timezone) etc.

Senhas, Manual, FAQ no Live MX Linux 19.2 KDE beta 2

Logo no início da sessão Live (KDE), o MX Updater indicou 10 pacotes atualizáveis. — Pelo apt, instalei o Synaptic, que usei para aplicar essas atualizações, — e também para instalar o Chromium.

As senhas da sessão Live estão no quadro de boas-vindas. — Um Manual e um FAQ ladeiam o ícone do MX Installer, em destaque na tela. — O quadro de boas-vindas oferece tudo isso e mais alguma coisa.

$ sudo apt update

We trust you have received the usual lecture from the local System
Administrator. It usually boils down to these three things:

    #1) Respect the privacy of others.
    #2) Think before you type.
    #3) With great power comes great responsibility.

[sudo] password for demo:              |    • demo    password:   demo
                                       |    • root    password:   root

Hit:1 http://deb.debian.org/debian buster-updates InRelease
Hit:2 http://deb.debian.org/debian buster InRelease
Hit:3 http://deb.debian.org/debian-security buster/updates InRelease
Hit:4 http://mxrepo.com/mx/repo buster InRelease
Reading package lists... Done
Building dependency tree
Reading state information... Done
10 packages can be upgraded. Run 'apt list --upgradable' to see them.

$ apt list --upgradable
Listing... Done
b43-fwcutter/mx 1:019-6~mx19+1 amd64 [upgradable from: 1:019-4]
firmware-b43-installer/mx,mx 1:019-6~mx19+1 all [upgradable from: 1:019-4]
firmware-b43legacy-installer/mx,mx 1:019-6~mx19+1 all [upgradable from: 1:019-4]
libnss3/stable 2:3.42.1-1+deb10u3 amd64 [upgradable from: 2:3.42.1-1+deb10u2]
libopenmpt-modplug1/stable 0.4.3-1+deb10u1 amd64 [upgradable from: 0.4.3-1]
libopenmpt0/stable 0.4.3-1+deb10u1 amd64 [upgradable from: 0.4.3-1]
lo-main-helper/mx,mx 20.07.02 all [upgradable from: 20.07.01]
mx-packageinstaller-pkglist/mx,mx 20.07.02 all [upgradable from: 20.07.01]
mx-tweak/mx 20.07.07 amd64 [upgradable from: 20.07.05]
virtualbox-guest-utils-modified-init/mx,mx 20.07.01 all [upgradable from: 20.02.02]


$ sudo apt install synaptic
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following additional packages will be installed:
  libept1.5.0 libvte-2.91-0 libvte-2.91-common
Suggested packages:
  dwww software-properties-gtk tasksel
The following NEW packages will be installed:
  libept1.5.0 libvte-2.91-0 libvte-2.91-common synaptic
0 upgraded, 4 newly installed, 0 to remove and 10 not upgraded.
Need to get 3,432 kB of archives.
After this operation, 10.2 MB of additional disk space will be used.
Do you want to continue? [Y/n]
...

Synaptic:


Commit Log for Wed Jul 22 13:32:48 2020

Upgraded the following packages:
b43-fwcutter (1:019-4) to 1:019-6~mx19+1
firmware-b43-installer (1:019-4) to 1:019-6~mx19+1
firmware-b43legacy-installer (1:019-4) to 1:019-6~mx19+1
libnss3 (2:3.42.1-1+deb10u2) to 2:3.42.1-1+deb10u3
libopenmpt-modplug1 (0.4.3-1) to 0.4.3-1+deb10u1
libopenmpt0 (0.4.3-1) to 0.4.3-1+deb10u1
lo-main-helper (20.07.01) to 20.07.02
mx-packageinstaller-pkglist (20.07.01) to 20.07.02
mx-tweak (20.07.05) to 20.07.07
virtualbox-guest-utils-modified-init (20.02.02) to 20.07.01


Commit Log for Wed Jul 22 13:43:08 2020

Installed the following packages:
chromium (83.0.4103.116-3~mx19+1)
chromium-common (83.0.4103.116-3~mx19+1)
chromium-sandbox (83.0.4103.116-3~mx19+1)

Documentação do /etc/fstab

Dentro da sessão Live KDE, mudei o Fuso horário para BRT (2 vezes!), alterei o Idioma / Formatos regionais (Locale) para United Kingdom - en_UK (Logout / Login para fazer efeito), personalizei o Spectacle, o Dolphin, o Kate, o Gwenview, o Relógio digital, meu Conky pessoal, o Teclado, além do Wallpaper e vários pequenos detalhes no ambiente.

Como não tinha certeza da sobrevivência da /home, salvei as Capturas de tela e outros arquivos em um Pendrive, — inclusive uma cópia do /etc/fstab da sessão Live, com os parâmetros do Swap, que tinha sido ativado automaticamente.

MX Installer

Instalador do MX Linux 19.2 KDE beta 2, após o exame inicial do hardware

17:50 - Ao iniciar o MX Installer, li a primeira mensagem da aba de Ajuda (à esquerda), — exibida enquanto o instalador examinava o hardware e apresentava a opção de alterar o Layout de teclado (que dispensei, naquele momento).

Instalação personalizada, em partições pré-existentes

Depois disso, alternei para a aba “Live Log”, durante alguns minutos, — e não sei se perdi alguma recomendação*. — Creio que não, pois voltei às mensagens logo no passo seguinte.

_________________
(*) Não tive essa preocupação na hora, — mas agora, ao examinar os registros, para este relato, notei que em 2018 havia mensagens bem diferentes. Ver “Referências (2018)”, Adiante.

Instalação personalizada em partições pré-existentes

Por padrão, o MX Installer exige só a partição-raiz do sistema, — e de fato, a mensagem da aba de Ajuda, que voltei a ler (à esquerda), diz que /home e Swap são opcionais. — Mas minha dúvida era quanto à partição /boot, que em geral não uso.

Lá no final da mensagem de Ajuda, ficou claro que uma partição /boot separada (e sem criptografia) só é necessária se a partição-raiz for criptografada, — o que não me interessava.

Alterei as etiquetas (Label) sugeridas, para Linux12 e Home12 (que uso nas outras distros, em dualboot), — e evitei configurar a partição Swap nesse momento, pois não vi garantias de que não tivesse seu identificador UUID modificado, numa eventual formatação, — o que afetaria todas as outras distros já instaladas.

O conceito de “formatar” nunca é claro, nos instaladores que já vi. — Em alguns casos, manteve o identificador UUID (Ubiquity); e também já vi casos em que mantém ou re-aplica até a etiqueta (Label) pré-existente, — mas no antigo instalador do Debian, já vi mudar o identificador UUID da partição Swap, e depois foi muito trabalhoso consertar o estrago nas ouras distros.

A única opção oferecida de não formatar* refere-se à /home. — Por isso, preferi configurar manualmente a partição Swap, mais tarde, — o que é muito simples e rápido.

___________________
(*) Dias depois, uma discussão sobre semântica (#275~283), no tópico do Fórum para acompanhamento do Beta 2, me deixou com a impressão de que essa opção não é nada do que eu imaginei.

Ao concluir essa etapa, o MX Installer apresenta um resumo do que será feito, — e ainda se pode voltar atrás para corrigir algum erro.

Opções de instalação do Grub

As capturas de tela dão a impressão de que o MX Installer propôs, automaticamente, instalar a “chamada” do Grub na partição ESP sda1.

Enquanto eu pensava e fazia capturas de tela (42 segundos), o progresso da instalação avançou de “Preparando as partições” (1%) para “Formatando a partição root” (2%) e passou a “Copiando o novo sistema” (8%).

Alteração do Hostname e exclusão do Samba

Alterei o Hostname proposto para “Linux12” e desabilitei o Samba.

Opções de Localização e Fuso horário

A julgar pelo tempo transcorrido (8 segundos), essas opções de Regionalização (Locale), Fuso horário (Timezone), Relógio do sistema (System clock = UTC) e formato de hora (24h) podem ter sido automáticas, com base nas configurações que fiz antes, na sessão Live.

Desabilitei apenas Cups

Não sei se levei 4 minutos pensando e lendo a lista de serviços, ou se fui buscar um café. — Só desabilitei Cups, pois não tenho impressora, e nunca precisei de Cups para “imprimir” arquivos em PDF, a partir do LibreOffice, Chromium etc.

Definição de Usuário, senha de Administrador, Auto Login, “persistência”

18:17 - No último diálogo, definem-se o Usuário padrão, a senha de Administrador, e aproveitei para configurar o Login automático, — além da “persistência” das alterações feitas na sessão Live, — que de fato foram transpostas para a instalação no computador, como pude constatar depois.

_____________
(*) Vou escrever “persistência” (entre aspas) sempre que me referir à instalação no computador, — pois na verdade, o termo se aplica a sessões Live USB.

O progresso da instalação ficou estacionado em 94%, aguardando pacientemente.

Após mandar prosseguir, o MX Installer ainda trabalhou mais 3 minutos, — em sua maior parte, instalação do Grub (grub-install), montagem de partições (grub-mount), detecção de outras distros (os-prober), — e por fim mkinitramfs.

18:20 - No aviso de “Instalação completa”, desarmei o boot automático ao fechar o MX Installer, e copiei mais algumas coisas da /home para o Pendrive, por via das dúvidas. — Ao reiniciar, uma mensagem lembra de retirar a mídia de instalação, para prosseguir.

Com toda atenção, tentando documentar o processo em numerosas capturas de tela, a instalação demorou exatos 30 minutos (17:50 ~ 18:20), desde a abertura do MX Installer.

Pós-instalação

Grub do MX Linux 19.2 KDE beta 2

18:30 - Ao reiniciar o computador, entrei na UEFI Bios utility, e coloquei o Grub do openSUSE outra vez no topo das prioridades de boot.

Em seguida, selecionei o Grub do MX Linux para executar só desta vez. — Apenas o openSUSE (em partição BtrFS) não apareceu no Menu de inicialização, — mas isso tem sido a norma, no Grub de quase todas as distros que experimentei, desde o início de 2017.

Não duvido que se possa resolver isso, mas basta o Grub do próprio openSUSE. — Em caso de emergência, o Grub do Mageia detecta (e consegue carregar) o openSUSE instalado em uma partição BtrFS.

Início da primeira sessão KDE após a instalação do MX Linux

18:35 - Com o Login automático, definido no MX Installer, ao final da primeira inicialização eu já estava na sessão Plasma KDE, — sem meu Conky personalizado, que eu tinha esquecido de configurar para iniciar com a sessão, — e sem exibir o papel de parede que apliquei na sessão Live, — o que talvez tenha sido a única falha real da “persistência”.

Enfim, reapareceram os ícones do FAQ e do Manual, deletados na sessão Live, — mas é possível que isto seja proposital. — Cabe ao usuário decidir que não precisa mais ser lembrado, o tempo todo, da existência desses recursos.

Apenas alterei a configuração do Spectacle, — pois agora a /home era definitiva e eu não precisava mais gravar as capturas de tela em um Pendrive.

Configurações do Painel, Dolphin, Conky preservadas na instalação

Todas as outras inúmeras mudanças feitas na sessão Live foram preservadas.

O Synaptic, o Chromium e as atualizações da sessão Live “persistiram” na instalação. — O Dolphin já abriu personalizado, e na mesma posição e tamanho. — Painel, Gerenciador de tarefas, Lançadores, Área de notificações, Relógio digital, Calendário, Spectacle, Kate, Gwenview etc. mantiveram as configurações feitas na sessão Live.

18:38 - O arquivo do Wallpaper “persistiu” em /home/Pictures, e bastou reaplicar.

18:40 - As configurações do Conky “persistiram” em ~/.config/conky/, e bastou iniciá-lo.

18:59 - Configurei o início automático do Conky(1) nas sessões KDE.

Colando no /etc/fstab um “bloco” de partições adicionais

19:02 - Para simplificar a montagem automática de 27 partições adicionais, nas distros baseadas no Debian (LMDE, Devuan, MX Linux), costumo colar no /etc/fstab um “bloco” de linhas pré-definidas, que basta copiar daqui do blog, com pequenos ajustes em cada caso.

Nessas linhas, adotei a montagem por etiquetas (Label), um caminho (path) simplificado, e plenos direitos ao Usuário, — que só precisa de autorização para escrever nas partições dos sistemas (Linux1 ~ Linux12). — Nas partições Home1 ~ Home12 e nas partições de trabalho (Sites, Works, XTudo, Depot1, Storage), o identificador de usuário UID=1000, comum a todas as distros, assegura total liberdade de gravação.

A montagem da partição Depot2, em uma unidade SSD externa plugável (USB2), é feita pelo uDev, e foi configurada em System settings >> Removable storage >> Removable devices, alguns dias depois.

Criando as pastas que servirão de pontos-de-montagem das partições adicionais

19:18 - Faltavam as pastas para servir de pontos-de-montagem das partições adicionais. — Fiz isso em “modo braçal”, recuperando (↑) e editando uns 27 comandos mkdir. — Sim, já devia ter criado um script para agilizar essa tarefa recorrente.

E, sim, podia ter usado o velho e bom Disk Manager. — Ver “Montagem de partições por udisks2 vs. fstab”, adiante.

Essas partições adicionais serão acessadas pelo usuário, por isso preferi criá-las usando sudo (usuário, embora com poderes), em vez de su (root). — Não tenho certeza, mas apenas certa impressão de que isso fez diferença, em alguma outra distro, no passado.

Dias depois, completei o /etc/fstab com as linhas do Swap copiadas da sessão Live, — e ativei com um comando # swapon --all:

# Pluggable devices are handled by uDev, they are not in fstab
UUID=49d82742-a532-487f-a044-8321e804e3b5 / ext4 defaults,noatime 1 1
UUID=7A0B-66EE /boot/efi vfat defaults,noatime,dmask=0002,fmask=0113 0 0
UUID=73f1fe8c-5617-4666-9b3c-ff28f9a2ce17 /home ext4 defaults,noatime 1 2
# Added by make-fstab /dev/sdb14
UUID=2ae5ec7d-42bd-4d6b-9597-7473984c75fe  swap  swap  defaults  0   0
LABEL=Storage    /media/Storage     ext4        defaults,user    0   0
LABEL=Depot1     /media/Depot1      ext4        defaults,user    0   0
LABEL=Sites      /media/Sites       ext4        defaults,user    0   0
LABEL=Works      /media/Works       ext4        defaults,user    0   0
LABEL=XTudo      /media/XTudo       ext4        defaults,user    0   0
LABEL=Linux1     /media/Linux1      btrfs       defaults,user    0   0
LABEL=Linux2     /media/Linux2      ext4        defaults,user    0   0
LABEL=Linux3     /media/Linux3      ext4        defaults,user    0   0
LABEL=Linux4     /media/Linux4      ext4        defaults,user    0   0
LABEL=Linux5     /media/Linux5      ext4        defaults,user    0   0
LABEL=Linux6     /media/Linux6      ext4        defaults,user    0   0
LABEL=Linux7     /media/Linux7      ext4        defaults,user    0   0
LABEL=Linux8     /media/Linux8      ext4        defaults,user    0   0
LABEL=Linux9     /media/Linux9      ext4        defaults,user    0   0
LABEL=Linux10    /media/Linux10     ext4        defaults,user    0   0
LABEL=Linux11    /media/Linux11     ext4        defaults,user    0   0
# LABEL=Linux12    /media/Linux12     ext4        defaults,user    0   0
LABEL=Home1      /media/Home1       xfs         defaults,user    0   0
LABEL=Home2      /media/Home2       ext4        defaults,user    0   0
LABEL=Home3      /media/Home3       ext4        defaults,user    0   0
LABEL=Home4      /media/Home4       ext4        defaults,user    0   0
LABEL=Home5      /media/Home5       ext4        defaults,user    0   0
LABEL=Home6      /media/Home6       ext4        defaults,user    0   0
LABEL=Home7      /media/Home7       ext4        defaults,user    0   0
LABEL=Home8      /media/Home8       ext4        defaults,user    0   0
LABEL=Home9      /media/Home9       ext4        defaults,user    0   0
LABEL=Home10     /media/Home10      ext4        defaults,user    0   0
LABEL=Home11     /media/Home11      ext4        defaults,user    0   0
# LABEL=Home12     /media/Home12      ext4        defaults,user    0   0

Breeze Dark + Maia transparent + Transparent oxygen + MX icon

19:26 - Não encontrei o recurso de Cor noturna (Night colour) nas Configurações do KDE (System settings >> Display and monitor) e resolvi mudar o tema geral, de Breeze para Breeze Dark, para aliviar a vista. — Aproveitei para instalar e aplicar na Área de trabalho o tema Maia transparent (19:30); e a Decoração de janelas Transparent oxygen (19:32). — Mais tarde, lembrei de mudar o ícone do Menu (20:58).

19:36 - Ativei a exibição dos Feriados (br_pt-br) no Relógio digital / Calendário. — Não encontrei a opção de habilitar Eventos astronômicos (talvez por ser KDE “antigo”), mas os Equinócios e Solstícios são exibidos. — Ficaram faltando as fases da Lua.

Weather

19:40 - Instalado e configurado o widget Moon phase (Gealach).

19:41 - Instalado widget Weather. — Faltava instalar o módulo QtQuick-XmlListModel (19:47) e reiniciar o KDE, para fazer efeito (20:16). — De passagem, percebi que “persistia” no Synaptic o histórico das atualizações e da instalação do Chromium no início da sessão Live.

Remoção do System Load Viewer

20:51 - Não sei exatamente como eliminei da Área de notificações (System tray) o widget System Load Viewer. — Provavelmente, do jeito como se remove qualquer widget. — Não sei se apenas eliminei a poluição visual, e se algum processo desnecessário continua rodando escondido.

Direcionando as teclas de atalho PrtScn e Shift+PrtScn ao gnome-screenshot

20:54 - Ativei o início automático do Conky(2), reiniciei o KDE para testar, e comecei a fazer os ajustes (21:13).

21:38 - Instalado gnome-screenshot e reconfiguradas as teclas de atalho PrtScn e Shift+PrtScn:

PrtScn:
gnome-screenshot -p -f /media/Storage/0_PrtScn/$(date +%F_%H-%M-%S)_Mx.jpg

Shif+PrtScn:
gnome-screenshot -p -d 7 -f /media/Storage/0_PrtScn/$(date +%F_%H-%M-%S)_Mx.jpg

Desabilitando os-prober e atualizando o Grub

22:03 - Desabilitada a detecção de outras distros (os-prober):

# date && update-grub && date
Wed 22 Jul 22:00:16 -03 2020
Generating grub configuration file ...
Found theme: /boot/grub/themes/linen/theme.txt
Found linux image: /boot/vmlinuz-5.6.0-2-amd64
Found initrd image: /boot/initrd.img-5.6.0-2-amd64
Found mtest-64.efi image: /boot/uefi-mt/mtest-64.efi
File descriptor 12 (/dev/dri/card0) leaked on lvs invocation. Parent PID 9217: /bin/sh
Found void on /dev/sda10
Found openSUSE Tumbleweed on /dev/sda2
Found Arch Linux (rolling) on /dev/sda3
Found Debian GNU/Linux bullseye/sid on /dev/sda4
Found Fedora 32 (KDE Plasma) on /dev/sda5
Found KDE neon User Edition 5.19 (18.04) on /dev/sda6
Found PCLinuxOS on /dev/sda7
Found Mageia 8 (8) on /dev/sda8
Found Linux Mint 20 Ulyana (20) on /dev/sda9
Adding boot menu entry for EFI firmware configuration
done
Wed 22 Jul 22:00:59 -03 2020


/etc/default/grub:

# If you change this file, run 'update-grub' afterwards to update
# /boot/grub/grub.cfg.
...
GRUB_DISABLE_OS_PROBER=true
...


# date && update-grub && date
Wed 22 Jul 22:03:49 -03 2020
Generating grub configuration file ...
Found theme: /boot/grub/themes/linen/theme.txt
Found linux image: /boot/vmlinuz-5.6.0-2-amd64
Found initrd image: /boot/initrd.img-5.6.0-2-amd64
Found mtest-64.efi image: /boot/uefi-mt/mtest-64.efi
Adding boot menu entry for EFI firmware configuration
done
Wed 22 Jul 22:03:59 -03 2020

MX Tweaks

Habilitando o usuário para tarefas administrativas

Eu lembrava a grande quantidade de configurações oferecidas pelo MX Tools (detalhe à esquerda, na imagem) e pelo MX Tweaks na edição Xfce, — mas um rápido exame dessas ferramentas, na sessão Live do MX Linux KDE Beta 2, me mostrou várias possíveis duplicações ou sobreposições às configurações do KDE System Settings, — por isso, resolvi fazer primeiro todas as configurações pelo próprio KDE, e deixar as configurações pelas ferramentas MX para o final, avançando com cautela, um passo de cada vez.

22:20 - Em um primeiro momento, me limitei a habilitar a senha do usuário principal para as tarefas de administração, — e apenas anotei a opção de habilitar a montagem de partições dos discos internos por usuários comuns (no alto, ao centro). — Ver “Montagem de partições por udisks2 vs. fstab”, adiante.

Gerenciador de repositórios

Restaurando os repositórios originais

24 Jul 2020 - O comando # apt update indicou problemas em um repositório, — de fato, um espelho na Bélgica, — alterado pelo MX Installer, suponho, devido a eu ter optado pela regionalização britânica.

Explorei o MX Repo Manager e, na aba “Individual sources”, cliquei em “Restore original APT sources”. — Uma mensagem informou que a restauração foi realizada, o espelho “adicionado pelo usuário” não foi tocado (sic), e a mudança teria efeito na próxima atualização.

Repeti o comando # apt update, tudo funcionou bem, e apliquei as atualizações pelo Synaptic.

Uma cópia da pasta /etc/apt/sources.list.d, antes do conserto, contém 4 arquivos. — Outra cópia feita depois contém 8 arquivos, sendo 4 backups.

2020-07-24 10:00

$ sudo apt update
[sudo] password for flavio:
Hit:1 http://deb.debian.org/debian buster-updates InRelease
Ign:2 http://mirror.adct.be/mx/mx/repo buster InRelease
Hit:3 http://deb.debian.org/debian buster InRelease
Err:4 http://mirror.adct.be/mx/mx/repo buster Release
  404  Not Found [IP: 2a0d:ef00:0:7::1 80]
Hit:5 http://deb.debian.org/debian-security buster/updates InRelease
Reading package lists... Done
E: The repository 'http://mirror.adct.be/mx/mx/repo buster Release' does not have a Release file.
N: Updating from such a repository can't be done securely, and is therefore disabled by default.
N: See apt-secure(8) manpage for repository creation and user configuration details.


$ cp -r /etc/apt/sources.list.d/ /BACKUP_1/

$ ls -l
total 16
-rw-r--r-- 1 flavio flavio 318 Jul 24 10:07 debian.list
-rw-r--r-- 1 flavio flavio  94 Jul 24 10:07 debian-stable-updates.list
-rw-r--r-- 1 flavio flavio 224 Jul 24 10:07 mx.list
-rw-r--r-- 1 flavio flavio 142 Jul 24 10:07 various.list


MX Repo Manager ---> Restore original APT sources


$ cp -r /etc/apt/sources.list.d/ /BACKUP_2/

$ ls -l
total 32
-rw-r--r-- 1 flavio flavio 319 Jul 24 10:11 debian.list
-rw-r--r-- 1 flavio flavio 318 Jul 24 10:11 debian.list~
-rw-r--r-- 1 flavio flavio  94 Jul 24 10:11 debian-stable-updates.list
-rw-r--r-- 1 flavio flavio  94 Jul 24 10:11 debian-stable-updates.list~
-rw-r--r-- 1 flavio flavio 135 Jul 24 10:11 mx.list
-rw-r--r-- 1 flavio flavio 224 Jul 24 10:11 mx.list~
-rw-r--r-- 1 flavio flavio 142 Jul 24 10:11 various.list
-rw-r--r-- 1 flavio flavio 142 Jul 24 10:11 various.list~


mx.list~

# MX Community Main and Test Repos
deb http://mirror.adct.be/mx/mx/repo/ buster main non-free
#deb http://mirror.adct.be/mx/mx/testrepo/ buster test

#ahs hardware stack repo
deb http://mirror.adct.be/mx/mx/repo/ buster ahs


mx.list

# MX Community Main and Test Repos
deb http://mxrepo.com/mx/repo/ buster main non-free
#deb http://mxrepo.com/mx/testrepo/ buster test


$ sudo apt update
Hit:1 http://deb.debian.org/debian buster-updates InRelease
Hit:2 http://deb.debian.org/debian buster InRelease
Get:3 http://mxrepo.com/mx/repo buster InRelease [11.1 kB]
Get:4 http://mxrepo.com/mx/repo buster/main amd64 Packages [397 kB]
Hit:5 http://deb.debian.org/debian-security buster/updates InRelease
Get:6 http://mxrepo.com/mx/repo buster/main i386 Packages [367 kB]
Fetched 775 kB in 2s (396 kB/s)
Reading package lists... Done
Building dependency tree
Reading state information... Done
3 packages can be upgraded. Run 'apt list --upgradable' to see them.

Detecção dos espelhos mais rápidos, pelo MX Repo Manager

27 Jul 2020 - A velocidade de download dos pacotes estava baixa.

Ainda pelo MX Repo Manager, pedi para selecionar os espelhos mais rápidos, — nas abas “MX repos” e “Debian repos”. — Naquele momento, o gerenciador escolheu UFAM (Manaus) para MX e Unesp para Debian. — Executar # apt update, em seguida, para carregar as informações dos novos repositórios ou espelhos.

Melhor velocidade de download de pacotes após nova detecção de espelhos mais rápidos

28 Jul 2020 - A velocidade de download dos pacotes ainda não estava boa, e fiz nova detecção dos espelhos mais rápidos. — Dessa vez, o gerenciador selecionou RNP-SC para Debian e UFAM para MX, — e a melhoria foi notável, com picos de até 26 MiB/s (200+ Mbps).

Nova detecção dos espelhos mais rápidos, pelo MX Repo Manager

29 Jul 2020 - Problemas com o espelho RNP-SC, embora a conexão estivesse boa. — Nova detecção dos espelhos mais rápidos alterou para Debian-BR e USP, — e o download das atualizações ficou ainda mais rápido.

Desativando o carregamento do MX Updater no início de cada nova sessão

Por ser um sistema operacional conservador (Debian stable), as atualizações do MX Linux costumam envolver poucos pacotes, por isso o gráfico de velocidade de download, no Conky, não é tão espetacular, — um pico de 24.162 KiB/s (23,6 MiB/s), de curta duração.

Examinando as configurações do MX Updater, finalmente descobri como evitar que ele seja carregado no início de cada nova sessão.

Eu já tinha removido o PackageKit, — o que, em várias distros, basta para desabilitar a verificação automática de atualizações, — e agora aproveitei para remover o Discover.

Commit Log for Fri Jul 24 10:26:37 2020

Completely removed the following packages:

packagekit
packagekit-tools


Commit Log for Wed Jul 29 11:53:32 2020

Removed the following packages:

discover
discover-data
libdiscover2

Prefiro verificar atualizações manualmente, pela manhã ou no final do dia, — e usar o Synaptic para aplicá-las, ou para pesquisar e instalar novos pacotes.

4 Agosto - De algum modo, ainda ocorre a verificação automática de atualizações.

Night colour vs. Redshift

Adicionando o controle do Redshift à Área de notificações do Painel do KDE

25 Jul 2020 - Desde quando comecei a usar o recurso de Cor noturna do KDE, em Dezembro, eu ainda não tinha experimentado nenhuma distro “Debian stable” (Buster), — e como ele sempre veio nas Configurações do sistema (KDE System settings), não sei de qual módulo ele depende, nem consegui descobrir agora, pelo Google. — Ignoro se é um recurso inexistente em versões mais antigas do Plasma KDE.

Pesquisando pelo Synaptic, arrisquei instalar o Redshift (seção: x11), que trouxe como dependência um “plasma-applet-redshift-control”. — Mais tarde, no mesmo dia, uma atualização do Redshift instalou o “geoclue”, como dependência, — mas não vi como utilizá-lo.

Só à noite, incomodado com alguma página branca, acabei encontrando, nas configurações da Área de notificações (Systray), um botão para habilitar o controle desse recurso.

Commit Log for Fri Jul 24 00:40:02 2020

Installed the following packages:

fonts-font-awesome (5.0.10+really4.7.0~dfsg-1)
plasma-applet-redshift-control (1.0.18-2+deb10u1)
redshift (1.12-2)


Commit Log for Fri Jul 24 10:19:01 2020

Upgraded the following packages:

desktop-defaults-mx-common (20.07.02) to 20.07.03
mx-user (19.10.01) to 20.7
redshift (1.12-2) to 1.12-2mx19+1

Installed the following packages:

geoclue-2.0 (2.5.2-1)

Não encontrei “redshift” entre os pacotes de nenhuma das distros com KDE, que instalei desde 2016, — incluindo as que eu ainda usava em Dezembro 2019, quando comecei a usar este recurso.

Ele só aparece entre os pacotes originais do LMDE3 (beta), mas associado ao GTK original, e não ao KDE que instalei em seguida. — Portanto, me parece que não tem relação com o “Night colour” nativo do KDE.

Ativando VLC e Redshift na Área de notificações do KDE

Em outra aba das configurações da Área de notificações do KDE, finalmente descobri como minimizar o VLC para um ícone, sem ocupar espaço no Gerenciador de tarefas (Task manager). — Isso também estava me incomodando, afinal, sempre vi o VLC ser exibido automaticamente na Área de notificações.

Ícone do Menu

Ícone “mxfcelogo-rounded”, um pouco grande demais

Há tempos, alguém me chamou atenção para “aquele ícone do Manjaro” no Menu de uma das minhas distros com KDE, — só assim (distraído como sou), percebi que o tema Maia transparent fazia essa alteração, por ser proveniente do Manjaro. — Depois disso, comecei a colecionar logos de cada distro, pois nem sempre eu conseguia encontrar nelas um ícone adequado ao papel de parede.

No MX Linux, o ícone que me agradou foi o “mxfcelogo-rounded”, — mas com o tempo comecei a achá-lo grande demais.

Ícone “MX_Linux_logo.svg”, um pouco mais discreto

Depois de algum tempo, adotei o “MX_Linux_logo.svg”, um pouco mais discreto, — e que já não lembro se baixei do site ou do Fórum. — Encontra-se na Wikimedia Commons.

Adaptações do “Rastergrafik_1.png”

No tópico de feedback sobre o MX Linux KDE Beta 2, um colega apontou outro problema que eu já tinha notado em várias distros: — Ao substituir o Menu-padrão pelo Menu em cascata (ou qualquer outro), o ícone das distros costuma ser substituído pela logo do KDE. — Na resposta #130, um colega postou o ícone “Rastergrafik_1.png”, combinando KDE + MX; e na réplica #147, outro colega apresentou sua personalização do mesmo ícone, com a engrenagem do KDE em azul e o MX em branco.

Na verdade, a história desse ícone vem de um tópico mais antigo (Janeiro 2019), e agora prossegue em um tópico de propostas de arte para o MX KDE.

Começando pelo “Rastergrafik_1.png”, inverti as cores, em seguida dupliquei a camada, — em uma, eliminei o KDE e deixei só o MX, — na outra, fiz o contrário.

Com isso, ficou fácil selecionar só a engrenagem do KDE, torná-la 100% branca, e experimentar várias tonalidades de azul. — O azul escuro se mostrou pouco visível contra o fundo vermelho escuro do papel de parede, e acabei adotando um azul um pouco mais claro. — Por fim, aumentei a área da imagem (canvas size) de 94 x 84 pixels para 120 x 107 pixels, para diminuir o tamanho aparente do ícone, dentro dela, e evitar que encoste nas margens da tela.

Pré-visualizações no Dolphin

Primeiras pré-visualizações adicionadas ao Dolphin

28 ~ 30 Julho - O Dolphin já indicava pré-visualização de arquivos KML na sessão Live (não verifiquei), — e pela instalação do Marble, adicionei a pré-visualização de arquivos KMZ.

Pela instalação do kdegraphics-thumbnailers, adicionei a pré-visualização de arquivos PDF.

Com a instalação de kdegraphics-mobipocket, adicionei a pré-visualização de arquivos Mobi.

Pré-visualização de arquivos no Dolphin

Dados Exif no Painel Informações (F11) do Dolphin

Após a instalação do libkf5baloowidgets-bin, o Painel Informações (F11) do Dolphin passou a exibir os metadados dos arquivos, — inclusive dados Exif das fotos.

Habilitando a visualização de arquivos TIFF no Dolphin e no Gwenvies

31 Julho - Por um dos diálogos no tópico de acompanhamento do MX Linux 19.2 KDE Beta 2, aprendi que a pré-visualização de arquivos TIFF, — assim como sua visualização no Gwenview, — podia ser ativada pela instalação do qt5-image-formats-plugins.

Eu já tinha observado o aparecimento dessa lacuna em algumas distros, em tempos recentes, — mas ainda não sabia como solucionar.

Pré-visualização de arquivos RTF e DOCX no Dolphin

3 Agosto - Por fim, instalei o Calligra, — primeiro, só algumas dependências (sem nenhum resultado); depois o resto, — para testar a pré-visualização de arquivos ODT e ODS.

Não é uma coisa muito garantida, — em geral, a visualização de planilhas ODS só ocorre em tamanhos menores, e colapsa quando se aumentam os ícones, ou a largura do painel Informações (F11), — mas não é uma coisa que eu use muito, pois em miniatura todas as planilhas se parecem; e costumo testar só por curiosidade.

As falhas e limitações foram as que eu já esperava, com base na experiência em 15 ou 20 distros nos últimos 2 anos. — O que me surpreendeu, foi a pré-visualização de um arquivo RTF, coisa que eu raras vezes vi funcionar, em outras distros, — mas ao tentar outras vezes, recebi 1 ou 2 mensagens de “kdeinit5 closed unexpectedly”.

Em 30 Julho, ao instalar alguns desses pacotes e verificar os resultados, entre 21:40 e 22:50, eu já tinha registrado 2 dessas mensagens crash do kdeinit5. — Elas oferecem um log de erro (às vezes bem extenso), para ser enviado aos desenvolvedores; e basta clicar em “Restart application”. — Desse modo, pude continuar trabalhando normalmente, entre a primeira mensagem de erro (22:06) e a segunda (22:30); e depois disso, por mais 20 minutos, até concluir o que queria.

Commit Log for Tue Jul 28 14:25:51 2020       --- Mobi preview in Dolphin

Installed the following packages:

kdegraphics-mobipocket (4:17.08.3-2)


Commit Log for Tue Jul 28 14:26:42 2020       --- PDF preview in Dolphin

Installed the following packages:

kdegraphics-thumbnailers (4:17.08.3-1)


Commit Log for Tue Jul 28 14:32:58 2020       --- KMZ preview in Dolphin

Installed the following packages:

libqt5serialport5 (5.11.3-2)
libshp2 (1.4.1-3)
marble (4:17.08.3-3.2)
marble-plugins (4:17.08.3-3.2)


Commit Log for Thu Jul 30 21:56:48 2020       --- Metadata (and Exif) in Dolphin's Info Panel (F11)

Installed the following packages:

libkf5baloowidgets-bin (4:18.08.1-1)


Commit Log for Thu Jul 30 22:26:05 2020       --- added "gettext"

Installed the following packages:

kdesdk-thumbnailers (4:17.08.3-1)
libgettextpo0 (0.19.8.1-9)


Commit Log for Fri Jul 31 17:29:16 2020       --- TIFF preview in Dolphin + TIFF view in Gwenview

Installed the following packages:

qt5-image-formats-plugins (5.11.3-2)


Commit Log for Mon Aug  3 22:21:42 2020       --- No effect

Installed the following packages:

calligra-data (1:3.1.0+dfsg-5)
calligra-libs (1:3.1.0+dfsg-5)
libkchart2 (2.6.1-1)
libphonon4qt5experimental4 (4:4.10.2-1)
libspnav0 (0.2.3-1)


Commit Log for Mon Aug  3 22:23:51 2020       --- ODT, ODS, DOC, XLS... previews in Dolphin

Installed the following packages:

calligra (1:3.1.0+dfsg-5)
calligrasheets (1:3.1.0+dfsg-5)
calligrasheets-data (1:3.1.0+dfsg-5)
calligrastage (1:3.1.0+dfsg-5)
calligrastage-data (1:3.1.0+dfsg-5)
calligrawords (1:3.1.0+dfsg-5)
calligrawords-data (1:3.1.0+dfsg-5)
karbon (1:3.1.0+dfsg-5)

Breeze dark no Synaptic, GParted, Disk Manager...

Aplicando algumas configurações do KDE na conta de Administrador

Outro curto diálogo no Tópico de feedback do MX-19.2 KDE Beta 2 (#191~197) me ensinou como colocar um tema dark no Synaptic, executando $ sudo systemsettings5 e fazendo nele as mesmas opções já feitas como usuário comum.

Synaptic com tema Breeze dark

O resultado foi ótimo, tanto no Synaptic quanto no GParted e no Disk Manager, — mas quando tentei fazer o mesmo no openSUSE Tumbleweed, não funcionou (ainda).

Montagem de partições por udisks2 vs. fstab

Configurando a regra de pontos de montagem (path) do udisks2

4 Agosto - Resolvi aproveitar a opção de permitir a montagem de partições extras como usuário comum, pelo MX Tweak, para retirar essa tarefa do /etc/fstab, e passá-la para o udisks2.

O primeiro passo foi configurar o udisks2 para usar os mesmos pontos de montagem (path) /media/[Label], que eu já havia adotado nas configurações personalizadas do Conky.

Para isso, bastava criar um arquivo /etc/udev/rules.d/99-udisks2.rules, com a regra de montar as partições internas em /media/[Label], — após me certificar que esse arquivo não existia, e fazer um backup da pasta inteira:

$ date && ls -o /etc/udev/rules.d/
Tue  4 Aug 13:25:37 -03 2020
total 8
-rw-r--r-- 1 root   97 Aug 12  2019 61-optical-polling-rules.rules
-rw-r--r-- 1 root 1143 Sep 14  2019 69-wacom.rules
-rw-r--r-- 1 root    0 Nov  6  2017 80-net-name-slot.rules
-rw-r--r-- 1 root    0 Nov  6  2017 80-net-setup-link.rules
-rw-r--r-- 1 root    0 Nov  6  2017 90-usb-semiauto.rules

$ date && cp -R /etc/udev/rules.d/ /[BACKUP]
Tue  4 Aug 13:31:25 -03 2020

$ date && sudo nano /etc/udev/rules.d/99-udisks2.rules
Tue  4 Aug 13:33:51 -03 2020

     Pasted:

     # UDISKS_FILESYSTEM_SHARED
     # ==1: mount filesystem to a shared directory (/media/VolumeName)
     # ==0: mount filesystem to a private directory (/run/media/$USER/VolumeName)
     # See udisks(8)
     ENV{ID_FS_USAGE}=="filesystem|other|crypto", ENV{UDISKS_FILESYSTEM_SHARED}="1"

Habilitando a montagem automática de partições no KDE System settings

Em KDE System settings >> Removable storage >> Removable devices, me certifiquei de que já estava habilitada a montagem automática de partições adicionais, — ou seja, as que não fazem parte do sistema (raiz, ESP, /home, Swap), — e que por isso são chamadas “removíveis”.

Habilitar também a opção de montar todas as mídias no início da sessão KDE, — de modo que eu não precisasse marcar cada uma das 27 partições extras. — Isso não afeta as partições do sistema, que são montadas antes, e não seriam selecionáveis, caso desabilitasse esta opção.

Já estava habilitada a opção de montar mídias, ao serem plugadas, — pendrive, celular, câmera digital, drives externos, — caso da partição “Depot2”, em um SSD externo USB2, que marquei para montar, tanto no início da sessão, quanto no caso de ser plugado depois.

Habilitando a montagem de partições internas pelo usuário

Em seguida, habilitar no MX Tweaks a montagem de partições dos discos internos pelo usuário.

Desabilitando as partições extras em /etc/fstab

Por fim, com tudo já pronto, desabilitei a montagem pelo /etc/fstab — com atenção, para não afetar as partições do sistema. — Utilizei o modo de seleção de bloco (Block selection mode) do Kate ou KWrite para comentar da linha nº 9 à linha nº 62, de uma vez só.

Note que o MX Linux havia adicionado comentários, tipo “# Entry for /dev/sdb12”, entremeados às linhas que eu colei, dias atrás, — e também eliminou as linhas que eu já colei desabilitadas.

23:16 - Depois de quase 10 horas (que aproveitei para atualizar este relato, entre outras coisas), chegou a hora do teste de fogo: — Reiniciar o computador.

Pontos de montagem duplicados (e não deletados) pelo udisks2

23:26 - Naturalmente, não podia dar certo logo na primeira tentativa. — Eu tinha de esquecer algum “pequeno” detalhe.

O udisks2 cria os pontos de montagem dinamicamente, no início da sessão, — e os deleta no final, por padrão. — Veja no detalhe (acima, à direita) a pasta /media do KDE Neon (Linux5), vazia, quando se olha “de fora” de uma sessão dele.

Quando já existem pontos de montagem (como os que criei manualmente), usando os mesmos nomes (Label, neste caso), udisks2 cria outros, acrescentando “1” no final para diferenciar, — mas o Conky, o Dolphin, o gnome-screenshot etc. não reconhecem o novo caminho (path). — E ao encerrar a sessão, o udisks2 deleta os pontos de montagem (com os nomes certos), o que deveria resolver o problema, para a sessão seguinte.

Na prática, não sei se resolve, pois não verifiquei. — Não resolvia, tempos atrás, — talvez porque na época eu os tivesse criado como root (su), e não como usuário (sudo).

Eu já havia passado por uma situação como essa, em 2016, e sabia que a solução mais simples era deletar todos os pontos de montagem, — de modo que o udisks2 possa criar os pontos certos, do modo certo, automaticamente.

A maneira usual de fazer isto, seria a partir de uma sessão Live, — mas achei mais simples aproveitar o dualboot para carregar o openSUSE, que oferece Dolphin e Krusader em modo root. — Bastou selecionar todos os pontos de montagem e mandá-los para a Lixeira.

Depois disso, o MX Linux 19.2 KDE Beta 2 carregou normalmente, com tudo funcionando dentro do esperado.

Montagem de partições adicionais em distros Linux

Menu: Favoritos e Recentes

Add caption

31 Julho - O Menu em cascata não mantinha os itens Favoritos, nem os Documentos e Aplicativos Recentes, — problema que eu já tinha enfrentado no PCLinuxOS e em mais uma ou outra distro, nos últimos 3 anos. — Tentei 2 possíveis soluções:

3:00 - Renomeei ~/.local/share/kactivitymanagerd/ — pois sua base de dados não apresentava sinais de atualização, desde o Restart das 19:04 do dia 22.

Essa dica foi encontrada por maverick74 no Fórum do openSUSE e repassada no Fórum do PCLinuxOS, no início de 2018:

it's probably a problem with the kactivitymanager database, which is used to store the favorites now (allows to have different favorites per activity e.g.)

19:38 - Re-atribuí a propriedade de todas as pastas e arquivos da /home ao usuário, — depois de tentar conferir os atributos de várias pastas e arquivos possivelmente relacionados ao problema, nos dias anteriores:

   81  2020-07-27_18-18-16   $ ls -n

  121  2020-07-31_19-38-20   $ sudo chown -R 1000 *

Add caption

2 Agosto - 14:30 - Ao inicializar o computador, nenhum resultado, — exceto que a sessão abriu com o Wallpaper-padrão do MX Linux (o que pode ter sido mais que uma coincidência), — mas data desse momento a criação de nova pasta, em substituição à que eu tinha renomeado.

3 Agosto - Nova inicialização do computador, — mas só no dia seguinte percebi que o problema tinha sido resolvido.

\\\\

KDE antigo e outros incômodos

Versões antigas do Gwenview não aceitam Esc para Sair.
Versões antigas do Gwenview não alternam Zoom entre Fit e 100% no mesmo botão
~~VLC não minimiza para a Área de notificações~~ [RESOLVIDO]
~~Falta módulo Night Colour no System Settings~~ [Contornei com Redshift]
~~Menu não mantém aplicações Favoritas, de uma sessão para outra~~ [RESOLVIDO]
~~Menu não mantém documentos nem aplicações Recentes, de uma sessão para outra~~ [RESOLVIDO]
Menu não inclui nova Captura de tela em Recentes
~~Dolphin não exibe informações dos arquivos no painel Info (F11), à direita~~ [RESOLVIDO instalando libkf5baloowidgets-bin]
~~Gwenview não abre arquivos TIFF e Dolphin não exibe pré-visualizações~~ [RESOLVIDO instalando qt5-image-formats-plugins]

Init

Carregamento do MX Linux (esq.), após detectar o hardware (dir.), na sessão Live

Concluídas as opções nos submenus da inicialização personalizada, o Live MX Linux examina os dispositivos do hardware, monta os dispositivos virtuais (detalhe à direita) e dá partida no init, que assume o comando daí por diante. — A versão “2.93” contrasta com as versões de número 240+ do SystemD, — mas eu nem notei isso, até examinar as fotos, mais tarde.

Como simples usuário, isso não faz diferença. Durante 10 anos, usando Kurumin, Kubuntu, Mint e Debian, passei por várias mudanças de init, entre 2007 e 2017, sem nem tomar conhecimento de que “isso existe”; — na verdade, mal me dando conta do que fosse Kernel, X, Gnome, Unity, KDE, Cinnamon etc., até 2016; nem jamais ter feito um chroot, até o final de 2019, — o que mostra o quanto o Linux já se havia tornado amigável e intuitivo, desde o início desse período. Eu mal usava um ou outro comando, copiado de algum site, uma vez ou outra.

Depois que eu já não dependia do Windows para nada, comecei a explorar os ramos principais do Linux, para eliminar também minha dependência da Canonical. — Esse novo aprendizado incluía distros sem-SystemD, para não ficar dependente de outras empresas, — mas nas primeiras experiências, com PCLinuxOS, Devuan, Slackware, antiX, MX Linux, tampouco tive de tomar conhecimento da existência do init de cada um. Só no Void (Novembro 2019), finalmente fui obrigado a ter consciência do Runit... mas isso não quer dizer que eu tenha aprendido mais do que o mínimo

Só 2 dias depois da sessão Live, comecei a pesquisar o básico, — como verificar qual init está no controle do MX Linux, ou de qualquer outra distro, — para tirar essa dúvida, nos casos em que isso não fique evidente:

MX Linux                                                                Debian

# ls -n /sbin/init                                                      $ ls -n /sbin/init
-rwxr-xr-x 1 0 0 53016 Feb 14  2019 /sbin/init                          lrwxrwxrwx 1 0 0 20 Jul  5 06:44 /sbin/init -> /lib/systemd/systemd

# ls -l /sbin/init                                                      $ ls -l /sbin/init
-rwxr-xr-x 1 root root 53016 Feb 14  2019 /sbin/init                    lrwxrwxrwx 1 root root 20 Jul  5 06:44 /sbin/init -> /lib/systemd/systemd

# ls -l /proc/1/exe                                                     # ls -l /proc/1/exe
lrwxrwxrwx 1 root root 0 Jul 24 06:59 /proc/1/exe -> /usr/sbin/init     lrwxrwxrwx 1 root root 0 Jul 29 13:54 /proc/1/exe -> /usr/lib/systemd/systemd

# cat /proc/1/comm                                                      # cat /proc/1/comm
init                                                                    systemd

# init --version                                                        # init --version
SysV init version: 2.93                                                 bash: init: command not found

# ps -p 1                                                               # ps -p 1
  PID TTY          TIME CMD                                                 PID TTY          TIME CMD
    1 ?        00:00:01 init                                                  1 ?        00:00:03 systemd

# stat /proc/1/exe | grep File                                          # stat /proc/1/exe | grep File
  File: /proc/1/exe -> /usr/sbin/init                                     File: /proc/1/exe -> /usr/lib/systemd/systemd

Tempos depois, fiz um registro da situação no PCLinuxOS, Void, Slackware, MX Linux, — e no Debian testing, para comparação:

==========
2020-09-27
==========

# ls -n /sbin/init
-rwxr-xr-x 1 0 0         40648   Sep  5  2015   /sbin/init*                            PCLinuxOS
lrwxrwxrwx 1 0 0            10   Jul 22 11:46   /sbin/init -> runit-init               Void
-rwxr-xr-x 1 0 0         48800   Jul  8 17:56   /sbin/init                             Slackware
-rwxr-xr-x 1 0 0         53016   Feb 14  2019   /sbin/init                             MX Linux
lrwxrwxrwx 1 0 0            20   Sep 21 15:28   /sbin/init -> /lib/systemd/systemd     Debian testing

# ls -l /sbin/init
-rwxr-xr-x 1 root root   40648   Sep  5  2015   /sbin/init*                            PCLinuxOS
lrwxrwxrwx 1 root root      10   Jul 22 11:46   /sbin/init -> runit-init               Void
-rwxr-xr-x 1 root root   48800   Jul  8 17:56   /sbin/init                             Slackware
-rwxr-xr-x 1 root root   53016   Feb 14  2019   /sbin/init                             MX Linux
lrwxrwxrwx 1 root root      20   Sep 21 15:28   /sbin/init -> /lib/systemd/systemd     Debian testing

# ls -l /proc/1/exe
lrwxrwxrwx 1 root root 0         Sep 27 11:14   /proc/1/exe -> /sbin/init*                 PCLinuxOS
lrwxrwxrwx 1 root root 0         Sep 27 14:47   /proc/1/exe -> /usr/bin/runit              Void
lrwxrwxrwx 1 root root 0         Sep 27 14:59   /proc/1/exe -> /sbin/init                  Slackware
lrwxrwxrwx 1 root root 0         Sep 27 17:04   /proc/1/exe -> /usr/sbin/init              MX Linux
lrwxrwxrwx 1 root root 0         Sep 27 19:03   /proc/1/exe -> /usr/lib/systemd/systemd    Debian testing

# cat /proc/1/comm
init                      PCLinuxOS
runit                     Void
init                      Slackware
init                      MX Linux
systemd                   Debian testing

# init --version
-                            PCLinuxOS
-                            Void
SysV init version: 2.97      Slackware
SysV init version: 2.93      MX Linux
-                            Debian testing

# ps -p 1
  PID TTY          TIME CMD
    1 ?        00:00:01 init          PCLinuxOS
    1 ?        00:00:01 runit         Void
    1 ?        00:00:00 init          Slackware
    1 ?        00:00:01 init          MX Linux
    1 ?        00:00:02 systemd       Debian testing

# stat /proc/1/exe | grep File
  File:  /proc/1/exe -> /sbin/init                    PCLinuxOS
  File:  /proc/1/exe -> /usr/bin/runit                Void
  File:  /proc/1/exe -> /sbin/init                    Slackware
  File:  /proc/1/exe -> /usr/sbin/init                MX Linux
  File:  /proc/1/exe -> /usr/lib/systemd/systemd      Debian testing

Cabe registrar que Debian testing, KDE Neon, Linux Mint 20 e Slackware são as distros que carregam mais rápido, — em torno de 19 a 21 segundos, no meu hardware, — todas com KDE.

Referências (2018)

Minha experiência, de Maio a Dezembro 2018, não foi fácil nem produtiva, — em grande parte, porque o MX Linux é um Debian altamente configurado, por “ferramentas” que eu não conhecia na época (e até hoje), — e quando instalei o KDE, sem primeiro explorar e desfazer as inúmeras configurações herdadas, o novo ambiente ficou bastante afetado.

Em geral, tento instalar e conseguir usar uma distro com KDE, primeiro, para depois ir aprendendo na medida em que preciso, enquanto trabalho normalmente, — mas no caso do MX Linux, eu teria de fazer o contário: mergulhar fundo no sistema de configurações, antes de obter um ambiente KDE “produtivo”, — e isso virou uma queda-de-braço, em que nem eu nem o MX Linux cedíamos, e resolvi deixar de lado, após 6 meses, para explorar outras distros da minha lista, com as quais acabei tendo resultados mais rápidos (Sabayon, Mageia, Fedora, Arch, já experimentados antes; e Void, de primeira, aproveitando a experiência de instalação do KDE no Arch).

Nada daquilo seria problema, se eu me dispusesse a trabalhar no Xfce, pelo menos durante o tempo necessário para explorar melhor o MX Linux, e só depois instalar o KDE, com calma. — Esse foi o meu erro, mas quando percebi, desanimei de começar tudo de novo.

Em meados de 2018, meu velho hardware (2008) parece ter sido responsável por uma dificuldade com o instalador GUI do MX Linux, — mas tive apoio dos usuários e desenvolvedores, no Fórum, e acabei resolvendo com o instalador CLI, que tinha funcionado de primeira no caso do antiX, pouco antes. — Esse companheirismo, bem como a paciência e atenção dos colegas, me deixaram ótima impressão da comunidade.

Viciado no KDE mais recente no Fedora, KDE Neon e “rolling-distros”, eu também me sentia cada vez menos atraído por distros baseadas no Debian stable, — Devuan, LMDE, — e fui deixando o MX Linux para depois.

MX Linux - Installer test (1)

MX Linux - Installer test (2)

Sem SystemD

Wallpapers

Imagem de Denys Mota em São Luís do Maranhão, 2015

1) Foto da Escadaria da Rua do Giz, em São Luís (Maranhão, 2015), por Denys Mota, — sem tratamento, — cortada automaticamente nas laterais, ao aplicar como Wallpaper.

2) Crowd Watching Show Inside the Dark Stadium · Free Stock Photo, — que escureci um pouco, no Gimp, para favorecer uma vaga impressão de ETs desembarcando de um OVNI.

3) Moai, statue, idol, easter island, starry sky full hd, hdtv, fhd, 1080p hd background, — que também tive de escurecer um pouco, para não interferir demais com legibilidade do Conky.

— … ≠ • ≠ … —

Without-SystemD

PC desktop UEFI / GPT

Ferramentas &tc.

Grub enlouquecido com 12 distros em multiboot

Debian's

Void Linux + KDE Plasma (UEFI-GPT)

noreply@blogger.com (Mboaba) — Tue, 14 Jul 2020 15:28:00 +0000

Void Linux com Plasma KDE e Kernel 5.7.9 •

Void Linux é uma distro “independente” (não-baseada em outra) e sem-SystemD — usa Runit.

A instalação é muito fácil, graças ao Void-Installer — mas só existem ISOs com LXDE, LXQt, MATE, Xfce, Cinnamon, Enlightenment. — Por experiência anterior, concluí que a ISO “mínima” (sem DE) é o melhor caminho para, depois, instalar o KDE.

A instalação do Plasma KDE foi muito facilitada por minha experiência recente, do final de 2019, — e ainda mais, por aquele registro detalhado, que agora pude seguir pelo celular.

Isto não é um “tutorial”. — Apenas um registro da minha experiência. — Fico feliz, se for útil para outros “usuários médios”, como eu.

Roteiro utilizado para a instalação do Void Linux + Plasma KDE

A maior diferença em relação a 2019 é que, agora, meu hardware é UEFI-GPT. — Afora isso, só tive de adequar os antigos pontos de montagem ao atual particionamento.

No novo hardware, segui as mesmas diretrizes que simplificaram minha vida desde 2009: — CPU Intel + Placa-mãe com iGPU Intel, — o que evita dores de cabeça, para quem não precisa de mais do que isso:

Processors: 6 × Intel® Core™ i5-9400 CPU @ 2.90GHz (min/max: 800/4100 MHz)
      Mobo: TUF B360M-PLUS - ASUSTeK COMPUTER INC.
      iGPU: Intel UHD Graphics 630 (Desktop)
    Memory: 15.5 GiB of RAM

Utilizei a imagem ISO void-live-x86_64-20191109.iso (411 MiB), disponível na página oficial de “/live/current”.

Menu inicial do Live Void Linux e instruções na tela de Login

No Menu de Boot do Live Void Linux, escolhi a opção-padrão, e cheguei à tela de Login, onde se apresentam as informações básicas:

     ********************************************************
     Two users are available to Log In:

          - root   passwd:  voidlinux
          - anon   passwd:  voidlinux

          - anon has sudo permissions (without a password)

     To start installation:

          # void-installer

     To install additional software:

          # xbps-install      (to install / update packages)

          # xbps-query        (to query for package info)
     ********************************************************

Fiz Login como root, nesse primeiro Console virtual (tty1), — e como usuário anon no segundo Console virtual (tty2, que acabei nem usando).

Por padrão, o perfil Root do Void Linux usa um Shell (-sh = dash) de poucos recursos. — Não tem o comando “history”, não permite recuperar comandos anteriores pelas setas para cima / para baixo (↓↑), nem mover o cursor à esquerda (←), para editar.

Pode-se comandar # exec bash (ou apenas # bash), para usar o Bash. — Isso não teve muita importância, na sessão Live do Void Linux, onde só executei 1 comando, # void-installer — mas foi muito útil mais tarde, no Void já instalado.

Menu do void-installer

O Void Installer oferece um Menu simples, com os passos fundamentais da instalação, — e volta ao Menu, no final de cada etapa, — de modo que é fácil mudar de ideia e alterar alguma opção feita antes.

Minhas opções foram:

Keyboard      - br-abnt2
Network       - eno1
Source        - Network
Hostname      - Linux9
Locale        - en_GB.UTF-8
Timezone      - America/Sao_Paulo
Root password
User account  - default groups
Bootloader    - No. — Graphical? - No.
Partition     - (Skipped)
Filesystems:
    - sda10   - /         — Create new filesystems? - No!
    - sdb10   - /home     — Create new filesystems? - No!
    - sdb14   - Swap      — Create new filesystems? - No!
    - sda1    - /boot/efi — Create new filesystems? - No!
Install       - Go!
Exit          - Reboot

Teclar a primeira letra é mais prático, nas listas quilométricas

Podem-se usar setas para cima e para baixo (↓↑), entre as opções oferecidas (e TAB para ir ao OK ou Back), mas nas listas muito longas é mais prático teclar a primeira letra. — No caso do teclado, fui encontrar ABNT2 em “b” de Brasil, não em “p” de Português.

Observe, à esquerda da lista, as setas e sinais em verde, para cima (↑-) e para baixo (↓+), — e à direita, o indicador de 10%, que dá uma ideia do número de opções existentes além desse ponto.

Habilitando a Rede no Void Installer

A Rede foi detectada automaticamente e bastou aceitar o uso de DHCP, para habilitar a conexão.

Instalar pacotes atualizados (do repositório oficial)

A opção de baixar os pacotes do repositório oficial é uma vantagem, pois evita a necessidade de atualizar tudo, logo após a instalação do Void Linux, — mas só oferece o “sistema básico”, — que é o que eu queria.

Se você quiser instalar o Void com um dos ambientes oferecidos, — LXDE, LXQt, MATE, Xfce, Cinnamon, Enlightment, — deve baixar a imagem ISO correspondente, e optar pelos pacotes que vêm nela.

Preenchimento do Hostname

O Void Installer não opôs nenhuma proibição à letra maiúscula no Hostname, — ao contrário de outros instaladores ou distros.

Regionalização (Locale) pela primeira letra do Idioma

Na Regionalização (Locale) do sistema, fui encontrar o país teclando a primeira letra do Idioma.

Inglês é a melhor opção, se você precisar copiar mensagens do sistema ou capturar telas, para pedir (ou oferecer) ajuda em fóruns internacionais, — e o formato britânico de datas é mais compatível com o do Brasil, sem deixar de ser inteligível mundo afora. — Isso não faz diferença, ao usar o LibreOffice ou o Chromium, que oferecem suas próprias configurações separadas de interface e de trabalho.

Seleção do Fuso horário (Timezone)

Para a seleção do Fuso horário (Timezone), bastou escolher América e teclar “s” para chegar bem perto de São Paulo, que corresponde à hora oficial da maior parte do Centro-Sul do Brasil (BRT).

Void Installer pede o apelido de Login, e só depois o nome completo

O Instalador do Void pede primeiro o apelido para Login, e só depois o nome completo do Usuário.

Seleção dos Grupos do Usuário

Me limitei a aceitar os Grupos sugeridos para o Usuário, e tudo funcionou muito bem até o momento:

$ cat group | grep flavio
     wheel:x:4:flavio
     floppy:x:8:flavio
     audio:x:12:flavio
     video:x:13:flavio,sddm
     cdrom:x:16:flavio
     optical:x:17:flavio
     kvm:x:24:flavio
     xbuilder:x:101:flavio
     flavio:x:1000:

Na dúvida, não instalei o “Bootloader”

A seleção do “disco” para instalar o “Bootloader” me deixou em dúvida, — pois esse “cardápio de discos” é do tempo em que uma pequena “chamada” para o Grub era gravada na trilha inicial MBR, e não se precisava pensar em termos de “partição”.

Minha reduzida experiência com UEFI (8 distros bem diversificadas) sugere que, provavelmente, o Bootloader seria instalado na partição EFI, — ou seja, em uma partição Fat32 (*) que tenha as flags boot, esp, — em qualquer disco onde fosse encontrada (não importando qual “disco” eu escolhesse). Mas... como ter certeza?

(*) Não tenho certeza se, em computador de mesa, seria aceita partição Fat16 ou Fat12.

Esse anacronismo não é exclusividade do Void-Installer. — Neste quesito, outros instaladores / outras distros, bastante populares, também conservam interfaces dúbias; ou inconsistentes, mesmo.

Por segurança, escolhi “Nenhum: - Gerenciar de outro modo”, — para resolver por mim mesmo, no futuro, se necessário. — Eu não vou usar o Grub do Void, por isso não preciso de uma “chamada” apontando para ele. — Posso fazer isso depois, se mudar de ideia.

Em seguida, o Void Installer perguntou se eu queria usar um “terminal gráfico” para o “Bootloader”. — Escolhi “Não”.

Existe aí uma confusão, — pois a mesma palavra (Bootloader) é usada em perguntas sobre 2 ações inteiramente diferentes.

No primeiro diálogo, trata-se de instalar uma “chamada” em um “disco” (na MBR ou numa EFI), — No segundo, trata-se de escolher entre gerar um Menu (do Grub) em modo gráfico ou em modo texto, — o que não faz diferença, se não vou usar o Grub do Void como padrão da máquina.

Como optei por não instalar a “chamada” em disco, o Void Installer apenas gerou o arquivo /boot/grub/grub.cfg. — Isso era tudo que eu precisava, para o Grub de outras distros (openSUSE, Mageia) detectá-lo e incluí-lo no meu Menu de inicialização.

Configuração da partição-raiz

Pulei a etapa de “Particionamento”, — pois todas as partições já estavam preparadas, — e fui direto para a configuração dos “Sistemas de arquivos e pontos de montagem”.

Aí, trata-se de selecionar as partições desejadas (uma de cada vez), — clicar em “Modificar”, — escolher o “Tipo” de cada uma (ext4, Swap, Fat32 etc.), — indicar seu ponto de montagem, — e dizer se deseja “Criar um novo sistema de arquivos” (Formatar).

Filesystems:
    - sda10   - ext4   - /           — Create new filesystems? - No!
    - sdb10   - ext4   - /home       — Create new filesystems? - No!
    - sdb14   - Swap   - Swap        — Create new filesystems? - No!
    - sda1    - Fat32  - /boot/efi   — Create new filesystems? - No!

Tive todo cuidado em me assegurar de que as partições não fossem formatadas, — principalmente a EFI e o Swap.

Resumo das operações que serão executadas ao instalar o Void

Ao clicar em “Instalar”, para iniciar a efetiva instalação do Void Linux no computador, apresentou-se um resumo das operações que seriam executadas, — com um aviso de que as partições marcadas para “Criar novo sistema de arquivos” (Formatar) teriam seus dados destruídos. — O usuário precisa estar muito seguro do que fez, pois não há nenhuma indicação concreta se, por descuido, marcou alguma das partições para formatar.

No meu caso, seria chato se formatasse a partição EFI (acho improvável, mas...), — ou se uma formatação alterasse o identificador UUID da partição Swap, compartilhada pelas outras 8 distros em dualboot. — Felizmente, eu tinha fotografado todos os passos, e bastou conferir as imagens.

Fim da instalação dos pacotes básicos do sistema

O download e instalação de apenas 126 pacotes foi muito rápido, cerca de 6 minutos (10:39 ~ 10:45).

Geração do Grub, ao final da instalação do Void

Mais 1 minuto foi gasto pela configuração (post-install) do Kernel e geração do Grub, — que detectou só o próprio Void, pois não conseguiu criar a pasta /var/lib/os-prober/mount. — Não fez falta, pois de qualquer modo eu iria desativar a detecção de outras distros (os-prober).

Com todos os cuidados e demoras na parte interativa, — incluindo leitura do registro da instalação anterior (2019) e pesquisa na documentação oficial, pelo celular, e as fotos, — a instalação levou 43 minutos, do Login na sessão Live (10:03 UTC-0300) até o Reboot (10:46).

Detecção do Void Linux pelo Grub do openSUSE

Uma vez que o Void Installer gerou seu /boot/grub/grub.cfg, o Grub do openSUSE não teve dificuldade em obter os dados necessários para incluí-lo no Menu de inicialização da máquina.

Após montar as partições do Void (Linux9, Home9) e incluí-las no Conky do openSUSE, ficou registrado que o Void ocupava apenas 954 MiB de sua partição-raiz, — e a pasta do usuário estava vazia.

Preparação para instalar o Plasma KDE no Void Linux

Logo após o Login como root no Void Linux instalado, iniciei a execução do Bash (detalhe menor, à direita), configurei a datação do bash_history e executei um # xbps-install -Suv para me certificar de que estava tudo atualizado.

Em seguida, instalei xorg, kde5, e habilitei dbus, sddm, NetworkManager, — mas quando tentei instalar kde5-baseapps não houve qualquer resposta:

    2  2020-07-13  11:19  # echo 'export HISTTIMEFORMAT="%F_H-%M-%S "' >> ~/.bashrc
    4  2020-07-13  11:20  # source ~/.bash_profile
    6  2020-07-13  11:23  # xbps-install -Suv
   13  2020-07-13  11:34  # xbps-install xorg kde5
   20  2020-07-13  12:02  # ln -s /etc/sv/dbus /var/service
   21  2020-07-13  12:02  # ln -s /etc/sv/sddm /var/service
   24  2020-07-13  12:06  # ln -s /etc/sv/NetworkManager /var/service

   28  2020-07-13  12:09  # xbps-query -l > ~/packages-4.txt
   30  2020-07-13  12:11  # xbps-install -S kde5-baseapps
   32  2020-07-13  12:13  # xbps-query -l > ~/packages-5.txt

Um comando # xbps-query -R kde5-baseapps indicou que ele deveria acarretar a instalação do Dolphin, Kate, Konsole, — mas isso não tinha acontecido.

Por sucessivos comandos # xbps-query -l, fui salvando listagens dos pacotes instalados, passo a passo, — e o arquivo packages-5.txt não apresentou nenhum acréscimo em relação ao packages-4.txt.

Insisti mais de uma hora (12:11 ~ 13:38), tentando entender por que não funcionava, — até que resolvi instalar Dolphin, Kate, Konsole, um de cada vez, — e seguir adiante:

   37  2020-07-13  12:17  # xbps-install -S alsa-utils
   ...
   94  2020-07-13  13:37  # xbps-install kwalletmanager
   ...
   98  2020-07-13  13:38  # xbps-install dolphin
  101  2020-07-13  13:41  # xbps-install kate5
  102  2020-07-13  13:44  # xbps-install gwenview
  104  2020-07-13  13:45  # xbps-install kcalc okular krename kruler kfind
  107  2020-07-13  13:49  # xbps-install khelpcenter konsole
  111  2020-07-13  13:52  # xbps-install chromium
  113  2020-07-13  13:59  # xbps-install gimp resynthesizer
  117  2020-07-13  14:05  # xbps-install void-repo-nonfree
  118  2020-07-13  14:06  # xbps-install void-repo-multilib
  119  2020-07-13  14:06  # xbps-install void-repo-multilib-nonfree
  120  2020-07-13  14:06  # xbps-install -Suv
-------------------- Restart --------------------

Além de mais alguns pacotes do KDE, — como o gerenciador do KWallet, Gwenview, KCalc, Okular, KRename, KRuler, KFind, — aproveitei para instalar logo o Chromium, o Gimp, e habilitar os sub-repositórios nonfree + multilib.

Com isso, estava pronto para reiniciar o computador e carregar o Void com o Plasma KDE.

Das primeiras sessões Plasma KDE (14:10 ~ 15:40; e depois 15:43 ~ 15:56) ficaram poucos registros. — Na primeira, criei um arquivo polkit / udisks2 autorizando a montagem automática de partições adicionais (sem requerer senha); e instalei o widget Moon phase (Gealach). — Na segunda, executei o # sensors-detect para reconhecer o hardware e configurar o lm_sensors; e instalei o widget Weather.

  121  2020-07-13  14:31  # nano /etc/polkit-1/rules.d/90-udisks2.rules
  122  2020-07-13  14:50  # sensors-detect

The content of /etc/polkit-1/rules.d/90-udisks2.rules:

// 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; } });

Configurando teclas de atalho para o gnome-screenshot

Essas 2 providências eram essenciais, para que o Conky pudesse rodar desde o início de cada sessão, — e o gnome-screenshot pudesse salvar automaticamente as Capturas de tela em uma partição de trabalho, comum a todas as distros instaladas.

System settings >> Shortcuts >> Custom shortcuts >> Right-click >> New >> Global shortcut >> Command / URL

PrtScn:
gnome-screenshot -p -f /run/media/flavio/Storage/0_PrtScn/$(date +%F_%H-%M-%S)_V.jpg

Shift+PrtScn:
gnome-screenshot -p -d 7 -f /run/media/flavio/Storage/0_PrtScn/$(date +%F_%H-%M-%S)_V.jpg

Primeiras medições do uso inicial de Memória RAM

Nesse meio-tempo, configurei o espaço de trabalho, editei o Wallpaper no Gimp, fiz ajustes no Conky, — e registrei as primeiras medidas do uso inicial de Memória RAM, — após adicionar o widget Moon phase (Gealach); e de novo após adicionar o widget Weather:

2020-07-13  15:43             465 MiB    with Moon
2020-07-13  16:00             485 MiB    with Moon + Weather
---------------------------------------------------
$ date && uptime --pretty && uptime --since && date
Thu 16 Jul 16:07:18 -03 2020
up 3 days, 8 minutes
2020-07-13 15:58:54
Thu 16 Jul 16:07:18 -03 2020
---------------------------------------------------
2020-07-16  19:43      23’’   477 MiB    |
2020-07-16  20:16      25’’   481 MiB    |
2020-07-16  20:32      24’’   480 MiB    |
2020-07-16  20:49      23’’   478 MiB    | Average:  24’’  478 MiB
                       24’’   478 MiB    |
2020-07-16  21:09      22’’   474 MiB    |
2020-07-16  21:16      26’’   481 MiB    |

Nos 3 dias seguintes, desabilitei a Pesquisa de arquivos (File Search) e mais alguns itens em Background services, no KRunner, Efeitos da área de trabalho etc., — e depois disso, o uso inicial de Memória RAM foi, em média, de 478 MiB, — o mais baixo, entre as distros instaladas nesse hardware, desde Janeiro 2020.

Nesses 3 dias de sessão contínua, percebi apenas 2 pequenas instabilidades na interface:

1) Eventuais irregularidades de renderização do Chromium, após abrir e fechar inúmeras abas do Youtube, durante 1 ou 2 horas, mantendo abertas outras 2 ou 3 abas do Youtube. — Bastou fechar o Chromium e abrir de novo, e o problema desapareceu. — Isso ocorreu em apenas 2 momentos, em 3 dias.

2) Eventuais irregularidades na Barra de tarefas (Taskbar). — Ao fechar determinado aplicativo, seu espaço não desaparecia da barra, e voltava a exibi-lo, de modo intermitente, como se ele ainda estivesse rodando. — Isso também ocorreu apenas 2 vezes, nesses 3 dias.

Bash

Alterei o shell padrão do Root — do dash para o bash:

# cat /etc/passwd
root:x:0:0:root:/root:/bin/sh
...

# usermod --shell /bin/bash root

# cat /etc/passwd
root:x:0:0:root:/root:/bin/bash
...

Áudio

Ativando canais no Alsa-Mixer

Com o pacote alsa-utils (instalado logo no início), executei o comando $ alsamixer [Arch Wiki], experimentei ativar alguns canais de áudio, (M: mute / unmute) e regulei o volume de cada um, até me certificar de que o que eu precisava, no momento, era colocar o Master (1º) e o Front (4º) em 100%.

Claro, ainda faltava habilitar o serviço:

     # ln -s /etc/sv/alsa /var/service/

A partir daí, pude regular os volumes relativos do VLC e do Chromium / Youtube, nos controles de cada um deles, — e o volume geral na caixa de som.

Configurações e widget do KDE ainda inabilitados

As teclas de Volume ainda não funcionam, e os recursos do KDE permanecem “vazios”, — configurações, controles, sons de notificação, — mas não fizeram muita falta, até agora.

Em 2019, instalei pulseaudio e tentei tudo que encontrei no Handbook, na Wiki (agora esvaziada) e em outras páginas, sem sucesso. — Agora, resolvi parar neste ponto, até aprender mais.

Espelho (Mirror)

Baixa velocidade de download, mesmo após trocar de espelho

O download de grandes pacotes estava muito lento, mas infelizmente não encontrei um espelho no Brasil.

Experimentei substituir o repositório principal (da Finlândia) por outro nos Estados Unidos, — o de Kansas City, para começar:

# ls /etc/xbps.d
# cp /usr/share/xbps.d/*-repository-*.conf /etc/xbps.d/
# sed -i 's|https://alpha.de.repo.voidlinux.org|https://alpha.us.repo.voidlinux.org/|g' /etc/xbps.d/*-repository-*.conf

Primeiro, verifiquei que a pasta /etc/xbps.d estava vazia. — Copiei para ela as configurações da pasta /usr/share/xbps.d — e nelas substituí um endereço pelo outro.

A velocidade de download não melhorou, naquele momento, — mas o problema poderia estar na minha conexão, que tem oscilado muito, ultimamente. — Resolvi monitorar a velocidade nos dias seguintes, antes de experimentar outros repositórios.

Melhor velocidade de download das atualizações

No dia 18 (Sábado), nova atualização apresentou download à média de 101 MB / 6 segundos = 16,8 MB/s (134.4 Mbps), — o que é bastante razoável, para uma conexão de 200 Mbps e um repositório situado em outro continente.

Infelizmente, as velocidades indicadas pelo xbps no Terminal são um tanto fantasiosas, — por exemplo, até 930 MB/s, em pequenos pacotes de assinatura, no dia 13, enquanto o Conky indicava 130 a 230 KiB/s.

Grub

Edição do /etc/default/grub no editor interno do Midnight-Commander (mcedit)

A instalação de um novo Kernel, com as atualizações do dia 16, mostrou que agora o Grub era capaz de detectar as outras distros.

Abri o arquivo /etc/default/grub no editor interno do Midnight-Commander (mcedit) e colei com CTRL+Shift+V uma linha para desabilitar os-prober.

Em seguida, voltei a atualizar o Grub:

# date && grub-mkconfig -o /boot/grub/grub.cfg && date
Thu 16 Jul 15:49:06 -03 2020
Generating grub configuration file ...
Found linux image: /boot/vmlinuz-5.7.9_1
Found initrd image: /boot/initramfs-5.7.9_1.img
Found linux image: /boot/vmlinuz-5.4.51_1
Found initrd image: /boot/initramfs-5.4.51_1.img
Found openSUSE Tumbleweed on /dev/sda2
Found Arch Linux (rolling) on /dev/sda3
Found Debian GNU/Linux bullseye/sid on /dev/sda4
Found Fedora 32 (KDE Plasma) on /dev/sda5
Found KDE neon User Edition 5.19 (18.04) on /dev/sda6
Found PCLinuxOS on /dev/sda7
Found Mageia 8 (8) on /dev/sda8
Found Linux Mint 20 Ulyana (20) on /dev/sda9
done
Thu 16 Jul 15:49:41 -03 2020

# cat /etc/default/grub
...
GRUB_DISABLE_OS_PROBER=true

# date && grub-mkconfig -o /boot/grub/grub.cfg && date
Thu 16 Jul 15:53:56 -03 2020
Generating grub configuration file ...
Found linux image: /boot/vmlinuz-5.7.9_1
Found initrd image: /boot/initramfs-5.7.9_1.img
Found linux image: /boot/vmlinuz-5.4.51_1
Found initrd image: /boot/initramfs-5.4.51_1.img
done
Thu 16 Jul 15:54:01 -03 2020

Comandos pós-KDE

Aplicativo corona-cli, instalado pelo npm

# history

  126  2020-07-13  16:23  # date && xbps-install -Suv && date
  128  2020-07-13  16:49  # xbps-install kwrite
  131  2020-07-13  16:58  # usermod --shell /bin/bash root
  135  2020-07-13  19:11  # date && xbps-install -Suv && date
  136  2020-07-13  19:11  # xbps-install vlc
  ...
  145  2020-07-13  19:27  # ln -s /etc/sv/alsa /var/service/
  ...
  158  2020-07-13  20:44  # xbps-query -R nodejs
  159  2020-07-13  20:44  # xbps-install nodejs
  160  2020-07-13  20:48  # npm i -g corona-cli
  161  2020-07-13  20:54  # xbps-install -S kimageformats
  162  2020-07-13  20:55  # xbps-install -S kdegraphics-thumbnailers kdegraphics-mobipocket
  163  2020-07-13  21:00  # xbps-install -S ffmpegthumbs
  164  2020-07-13  21:01  # xbps-install -S marble5
  166  2020-07-13  21:20  # cp /usr/share/xbps.d/*-repository-*.conf /etc/xbps.d/
  167  2020-07-13  21:22  # sed -i 's|https://alpha.de.repo.voidlinux.org|https://alpha.us.repo.voidlinux.org/|g' /etc/xbps.d/*-repository-*.conf
  168  2020-07-13  21:23  # xbps-install -Suv
  170  2020-07-13  21:24  # xbps-install -S ImageMagick
  171  2020-07-13  21:25  # xbps-install -S libreoffice
  172  2020-07-13  21:53  # xbps-install -S kamera
  173  2020-07-13  21:54  # xbps-install -S android-file-transfer-linux
  174  2020-07-13  22:09  # xbps-install -S ktorrent
  176  2020-07-14  11:22  # date & xbps-install -S inxi
  191  2020-07-15  22:19  # date && xbps-install -S youtube-dl && date
  192  2020-07-15  22:58  # date && xbps-install -S ffmpeg && date
  ...
  210  2020-07-16  15:49  # date && grub-mkconfig -o /boot/grub/grub.cfg && date
  211  2020-07-16  15:51  # mc
  213  2020-07-16  15:53  # date && grub-mkconfig -o /boot/grub/grub.cfg && date

\\\\

Observações

Situação das distros instaladas, em 16 Julho 2020

O Quadro (acima) não é uma comparação técnica das distros. — É apenas um registro daquilo que eu já consegui obter (e do que ainda falta fazer), alterando-as o mínimo possível, para não descaracterizá-las. — Em todas elas, desativei a verificação automática de atualizações, bem como o KDE-PIM (Personal Information Management) e a Pesquisa de arquivos (File search), entre outros serviços do KDE.

No openSUSE, mantive os serviços de manutenção do Snapper + BtrFS. — No Mageia, mantive os serviços do MSEC (Mandriva security) e apenas desabilitei a verificação periódica. — No PCLinuxOS, o uso inicial de Memória RAM aumentou sensivelmente depois que adotei o UXA, em uma tentativa (frustrada) de conseguir rodar o GoogleEarth. — No Linux Mint, ainda não eliminei heranças do Xfce, que podem estar ocupando Memória RAM.

RAM usage at startup               Boot time

479 MiB   Void Linux               0’18’’   Debian testing
512 MiB   KDE Neon (Bionic)        0’18’’   Mint 20 beta (+KDE)
523 MiB   Arch Linux               0’20’’   KDE Neon (Bionic)
595 MiB   Debian testing           0’22’’   PCLinuxOS
606 MiB   Mageia 7                 0’24’’   Void Linux
607 MiB   Fedora 32                0’25’’   Arch Linux
628 MiB   openSUSE Tumbleweed      0’29’’   Mageia 7
628 MiB   Mint 20 beta (+KDE)      0’34’’   Fedora 32
660 MiB*  PCLinuxOS                0’34’’   openSUSE Tumbleweed

Average values for July, 1 to 16

No dia-a-dia, não faz diferença se o Boot demora alguns segundos a mais ou a menos, — e com 16 GB de Memória RAM tampouco faz diferença, se uma distro usa 180 MiB a mais ou a menos, ao ligar o computador. — Mesmo no meu antigo hardware, com apenas 4 GB RAM, nenhuma dessas distros (com KDE) apresentou problemas, mesmo após 3 ou 4 dias de uso intensivo, sem desligar, desde que eu não mantivesse muitas abas abertas no navegador.

Feitas essas ressalvas, — e lembrando que não jogo, não edito vídeos, não faço compilações, e me atenho aos repositórios oficiais (ou quase oficiais), — não tenho tido problemas com as distros rolling-release, nem com Kernels muito novos (mesmo no antigo hardware, de 2009, que usei até o início de 2020), nem com o KDE mais novo.

Wallpaper

Ajuste de Níveis do Wallpaper no Gimp, para tornar o Conky legível

“Forte da Barra PB” (08:10, 20 August 2011), by DlauriniJr. — Category: Forte de Santo Antônio da Barra (Salvador, BA), no Wikimedia Commons.

Esta imagem foi drasticamente “ajustada” no Gimp, — para escurecer as áreas muito claras das nuvens e da espuma / névoa das ondas do mar, de modo a deixar legíveis as informações do Conky, — sem escurecer demais as muralhas do Forte.

Ponta do Forte / Farol da Barra, Salvador, Bahia

«O Farol da Barra, ou Farol de Santo Antônio, localiza-se na antiga ponta do Padrão, atual Ponta de Santo Antônio, em Salvador, no litoral do estado da Bahia, no Brasil. O farol primitivo foi o segundo existente em todo o continente americano, antecedido somente pelo farol do antigo Palácio de Friburgo no Recife» (Wikipedia).

_____________________
• Inicialmente publicado em 2020-07-14 00:28
• Desenvolvido em sessão contínua do Void KDE até...

— … ≠ • ≠ … —

PC desktop UEFI / GPT

Não-debians

Mageia 8 alpha 1 Plasma KDE

noreply@blogger.com (Mboaba) — Fri, 03 Jul 2020 01:50:00 +0000

Mageia 8 alpha 1, com 319 pacotes atualizados durante a instalação

ddd

— … ≠ • ≠ … —

PC desktop UEFI / GPT

Não-debians

Upgrade para Fedora 32

noreply@blogger.com (Mboaba) — Mon, 29 Jun 2020 13:17:00 +0000

Fedora 32, ao final do upgrade

Fedora 32 foi lançado em 28 Abril mas, como eu estava envolvido com outras atividades, deixei para depois. — Só em 27 Junho aproveitei uma folga, após atualizar todas as distros, e fiz o upgrade para o Fedora 32.

O processo de upgrade do Fedora é muito simples e seguro, — e eu tinha feito o upgrade para Fedora 31 há apenas 8 meses, — por isso me limitei a copiar os comandos da Documentação rápida (atualizada), para evitar algum erro de digitação:

# dnf upgrade --refresh

# dnf install dnf-plugin-system-upgrade

# dnf system-upgrade download --releasever=32

# dnf system-upgrade reboot

Boa velocidade de download, na última atualização do Fedora 31

Em resumo, o que fazem esses 4 comandos:

Atualizar o Fedora 31

Instalar o plugin do dnf que fará o upgrade para Fedora 32

Usar o plugin para baixar todos os pacotes do Fedora 32

Usar o plugin para reiniciar a máquina e automaticamente realizar a instalação dos novos pacotes, bem como a remoção dos antigos, e demais ajustes

Verificação de atualizações, imediatamente antes de iniciar o upgrade

O histórico do bash registra que atualizei o Fedora 31 às 13:18, mas parece ter perdido a lembrança de que tornei a verificar às 14:58:

  359  2020-06-27_13-18-57  # date && dnf upgrade --refresh && date

  360  2020-06-27_14-58-41  # dnf install dnf-plugin-system-upgrade
  361  2020-06-27_14-59-55  # dnf system-upgrade download --releasever=32
  362  2020-06-27_15-15-08  # dnf system-upgrade reboot

Download de 2.116 pacotes em 4’27’’

O download de 2.116 pacotes (2,6 GB) foi feito em 4’27’’, a uma média de 9,8 MB/s, — o que é bastante razoável, embora a conexão de 200 “megas” (Mbps) seja equivalente a 25,0 MB/s. — Na prática, isso depende também dos repositórios (nominalmente, do exterior), ou de algum eventual redirecionamento para espelhos mais próximos.

Após baixar todos os pacotes do Fedora 32, fui intimado a concordar com as chaves de segurança dos novos repositórios, — coisa que eu nem saberia como verificar.

Restava fechar todos os aplicativos e executar o último comando, — que reinicia a máquina e aplica o upgrade de modo automático, em ambiente de linha de comando (CLI), — fora de qualquer ambiente gráfico (DE).

Grub ainda apontando para o Fedora 31

Até aí, permanecia instalado apenas o Fedora 31, — por isso não vi inconveniente em usar o Grub anterior, ainda inalterado.

Tarefas automáticas de upgrade para o Fedora 32

Uma vez reiniciada a máquina e carregado o (ainda) Fedora 31, não há o que fazer. — O dnf system-upgrade reboot assumiu todo o controle, e não lembro de ele ter me perguntado nada. — Resta ir tomar um longo café, ou ficar assistindo o desfile de milhares de linhas no Console.

Durante uns 10 minutos (15:16 ~ 16:26), desfilaram cerca de 2.100 mensagens de “Atualizando” pacotes (Fedora 32), — depois, uns 4 minutos (15:26 ~ 15:30) com outras tantas mensagens de “Limpeza” de pacotes (Fedora 31), — a seguir, mensagens de execução de scriptlets, verificação de pacotes, — e por fim, limpeza do cache de pacotes e nova reinicialização (15:35).

Seleção do Grub do Fedora 32 no UEFI Bios Utility, para carregar a nova versão

Nesse ponto, achei necessário entrar no UEFI Bios Utility para usar (só desta vez) o Grub do próprio Fedora 32, — o único Grub que já “sabia” do upgrade, novo Kernel etc., — e tirei os dados para uma comparação com a situação anterior (registrada durante o download):

=====================================================================================
2020-06-27        14:56                                        15:40
=====================================================================================
Operating System: Fedora 31               |  Operating System: Fedora 32
      KDE Plasma: 5.17.5                  |        KDE Plasma: 5.18.5
  KDE Frameworks: 5.70.0                  |    KDE Frameworks: 5.70.0
              Qt: 5.13.2                  |                Qt: 5.14.2
          Kernel: 5.6.19-200.fc31.x86_64  |            Kernel: 5.6.19-300.fc32.x86_64

         konsole: 19.12.1                 |           konsole: 20.04.1
         dolphin: 19.12.1                 |           dolphin: 20.04.1
            kate: 19.12.1                 |              kate: 20.04.1
        gwenview: 19.08.3                 |          gwenview: 19.12.1
=====================================================================================

Depois disso, voltei a usar meu Menu de inicialização, — gerenciado pelo Grub do openSUSE, — que esqueci de atualizar, e continuava apontando para o último Kernel do Fedora 31.

O Fedora costuma manter 3 versões de Kernel, — neste caso, o Kernel 5.6.19-300-fc32, e as 2 últimas revisões do “fc31”, — por isso, continuei usando o último Kernel do Fedora 31, nos dias 28, 29 e 30, sem perceber (e sem nenhum problema aparente).

Só me dei conta agora, ao chegar a este ponto do relato — e examinar vários detalhes.

Chromium

Chromium-Freeworld, com as mesmas abas e configurações do Chromium

Horas depois de concluir o upgrade para Fedora 32, percebi que o Chromium não era mais capaz de reproduzir vários vídeos encontrado nas redes sociais.

Por algum motivo, tinha desaparecido o pacote chromium-libs-media-freeworld, — que eu havia instalado em Janeiro 2020, em complemento ao chromium, chromium-common, chromium-libs e chromium-libs-media, — tal como havia feito no ano passado, ao instalar o Fedora 30 no antigo hardware.

Esse pacote não tem versão para Fedora 32, segundo rmpfind e repology, — ou tem, com nome invertido, segundo o pkgs (todos verificados em 30 Jun 2020), — mas não nos repositórios que habilitei.

Ao pesquisar, uma postagem me chamou a atenção para o chromium-freeworld (ex chromium-vaapi), que substitui o Chromium, em vez de apenas complementá-lo.

Removi o Chromium, instalei o chromium-freeworld, e o problema ficou resolvido.

$ rpm -qa | grep chromium
chromium-common-81.0.4044.138-1.fc32.x86_64
chromium-81.0.4044.138-1.fc32.x86_64


$ dnf search chromium
Fedora 32 openh264 (From Cisco) - x86_64                                                       1.8 kB/s | 5.1 kB     00:02
Fedora Modular 32 - x86_64                                                                     2.2 MB/s | 4.9 MB     00:02
Fedora Modular 32 - x86_64 - Updates                                                           2.0 MB/s | 3.5 MB     00:01
Fedora 32 - x86_64 - Updates                                                                   8.7 MB/s |  17 MB     00:01
Fedora 32 - x86_64                                                                             9.4 MB/s |  70 MB     00:07
google-earth-pro                                                                                24 kB/s | 5.3 kB     00:00
RPM Fusion for Fedora 32 - Free - Updates                                                      126 kB/s | 523 kB     00:04
RPM Fusion for Fedora 32 - Free                                                                216 kB/s | 679 kB     00:03
RPM Fusion for Fedora 32 - Nonfree - Updates                                                    30 kB/s |  74 kB     00:02
RPM Fusion for Fedora 32 - Nonfree                                                              81 kB/s | 225 kB     00:02
=============================================== Name Exactly Matched: chromium ================================================
chromium.x86_64                   : A WebKit (Blink) powered web browser
============================================== Name & Summary Matched: chromium ===============================================
chromium-browser-privacy.x86_64   : Chromium, sans integration with Google
chromium-common.x86_64            : Files needed for both the headless_shell and full Chromium
chromium-freeworld.x86_64         : Chromium web browser built with all freeworld codecs and VA-API support
chromium-headless.x86_64          : A minimal headless shell built from Chromium
chromium-libs.x86_64              : Shared libraries used by chromium (and chrome-remote-desktop)
chromium-libs-media.x86_64        : Shared libraries used by the chromium media subsystem
...

# dnf remove chromium chromium-common
Dependencies resolved.
...
Removed:
  chromium-81.0.4044.138-1.fc32.x86_64   chromium-common-81.0.4044.138-1.fc32.x86_64   minizip-compat-1.2.11-21.fc32.x86_64
  pipewire0.2-libs-0.2.7-2.fc32.x86_64

Complete!


# dnf install chromium-freeworld.x86_64
Last metadata expiration check: 2:33:48 ago on Sat 27 Jun 2020 23:55:10 -03.
Dependencies resolved.
...
Installed:
  chromium-freeworld-83.0.4103.106-1.fc32.x86_64    libva-utils-2.7.1-1.fc32.x86_64    minizip-compat-1.2.11-21.fc32.x86_64
  pipewire0.2-libs-0.2.7-2.fc32.x86_64

Complete!

Tornando Chromium-Freeworld navegador padrão e associando a tipos de arquivos

Chromium-Freeworld abriu com a mesma configuração e as mesmas abas da última sessão do Chromium. — Só tive de substituir o lançador no Painel, — e refazer as associações de arquivos (htm, bookmarks), além de torná-lo navegador padrão (em System settings >> Applications).

Nos arquivos /var/log/dnf.log e /var/log/dnf.rpm.log, não encontrei nenhum indício de que o pacote chromium-libs-media-freeworld tenha sido removido durante o upgrade para Fedora 32.

Pelo contrário, meu registro pessoal de atualizações (em TXT) indica que ele foi “substituído” (assim como o chromium-libs e o chromium-libs-media) pelo próprio Chromium, em 16 Maio. — Por que essas 3 substituições não afetaram a exibição de vídeos nas redes (ou por que só percebi agora), ainda é um mistério.

Gimp

O Gimp manteve várias configurações anteriores, mas “perdeu” outras, — como exportar imagens em JPEG, por padrão, — mas ao entrar nas “Preferências”, muitos itens estavam quase ilegíveis.

Tive de corrigir isso em:

System settings >> Application style >> Configure Gnome / GTK applications style

Adicionar legenda

As opções estavam vazias. — Escolhi “Default” para GTK3 theme; e Adwaita-dark para GTK2 theme. — Isso bastou para tornar legíveis as configurações nas “Preferências” do Gimp.

Simplificando a Caixa de ferramentas e salvando as configurações de imediato

Também tive de recriar as teclas de atalho que desapareceram, — “X” >> Cortar para a seleção; e “S” >> Salvar como, — além de ocultar novamente quase todos os itens da Caixa de ferramentas, para deixá-la mais simples, só com os ícones que uso o tempo todo (para as demais ferramentas, prefiro o Menu em texto).

Para encerrar, “Salvar as opções de ferramentas agora”.

\\\\

Quadro comparativo das distros Linux instaladas, em 28 Junho 2020

xxxx

— … ≠ • ≠ … —