Translate

quarta-feira, 23 de abril de 2025

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

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 obter (nem povoar) 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

xxx

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 gráfica, utilizando o navegador Firefox (1, 2, 3).

O Anaconda “tradicional” segue o formato básico “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).

  • Não percebi diferença 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, senti mais dificuldade, talvez pelo choque de encontrar uma página ilegível, reverter o tema dark, e ter de fechar o instalador e começar tudo de novo.

Desta vez, a escolha do layout de Teclado não foi tão óbvia, para mim. — Minha primeira opção mostrou-se totalmente errada, mais tarde, 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.

  • Uso qualquer distro para olhar ou editar alguma coisa nos arquivos de sistema de qualquer outra — mas é difícil (e perigoso) lidar com a árvore de arquivos do BtrFS a partir de outra distro.

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 esqueci da 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 não aparece. — Dependendo 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. É 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 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

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 neste caso não foram exibidos (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?

Localização 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 foram modificados, ou 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 (além da re-numeração e da prioridade de boot), 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 desaparece quando se desliga o computador.

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, mesmo que sem seguir qualquer “ordem” racional — 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
  • Corrigir alguns “lançadores rápidos” (Quick Launch) — chamar “systemsettings” em vez de “systemsettings5”, por exemplo
  • Eliminar widgets que só funcionavam no Plasma 5 — ou trocá-los por outros, que funcionem no Plasma 6
  • Configurar o KDE Spectacle para pular o diálogo e salvar 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” apareceu 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, específico para o Chrome; do RPM Fusion, apenas “Nonfree”, especificamente 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, e instalei pelo comando dnf — e foi automaticamente adicionado () 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:

Command:

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

# dnf remove korganizer kmail akregator kaddressbook akonadi-server mariadb-common
# 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, como Kate, Conky, lm_sensors, Midnight Command (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 alguns ajustes em seus arquivos de configuração. — O aspecto 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 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 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 — sem que eu tivesse feito mais nada, para isso.

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

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

— … ≠ “•” ≠ … —

Fedora

PC desktop UEFI / GPT

Ferramentas &tc.

domingo, 19 de maio de 2024

Neofetch parou? Viva o Fastfetch!

Fastfetch configurado para ocultar IP e outros dados
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, é mais adequada a saída de texto (não a imagem!) de um comando inxi (por exemplo), 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
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))";\
    MEM_USED_BYTES_X_1000="$(($MEM_USED_KILO*1000))";\
    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

    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

    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.