Translate

quarta-feira, 23 de abril de 2025

Fedora 42 - 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 não 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 durante a 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 estão as coisas, atualmente. Mas, sem deletar a instalação antiga.

O Fedora 41 KDE já está configurado do meu jeito, com todos os aplicativos de que preciso, e pretendo fazer upgrade dentro de 2 ou 3 semanas. — Nenhum motivo para deletar aquela instalação.

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 do Fedora 42 ocupou 7,4 GiB em disco — e depois de instalar alguns softwares (total: 2.327 pacotes), aumentou para 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 QuickLauncher (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
  • Sessão Live
  • Instalação

xxx

Download

Verificação da imagem ISO do Fedora 42 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 sha256sum — 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, apareceu o Grub da ISO, e carreguei a sessão Live Fedora 42 KDE — sem perder tempo verificando (de novo) sua integridade.

Sessão Live

\\\\

Fiz apenas as configurações indispensáveis para adequar a sessão Live Pendrive aos meus hábitos de trabalho: — KDE Spectacle, Dolphin, Gwenview etc. — e documentei o Menu, o Welcome Center etc. em capturas de tela.

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 que fechei o instalador, reabri, e comecei tudo de novo.

Instalação

O instalador do Fedora 42 KDE Live ainda era o Anaconda

A ISO do Fedora 42 KDE Live veio com o tradicional instalador Anaconda, que pode ser comparado a uma área central com acessos para 6 seções — Teclado, Data & Hora, Rede & Nome de Host, conta Root, Criação de Usuário, e Destino da Instalação — que você pode percorrer em qualquer ordem, quantas vezes quiser, mudando e tornando a mudar as configurações em cada uma delas — 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 houve muita diferença em relação ao que registrei, em meados de 2019, na instalação do Fedora 30 no meu antigo computador (Bios / MBR) — ou na do Fedora 31, no novo PC (UEFI / GPT), em 2020.

Agora, 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

Eu sempre opto pelo particionamento Personalizado — pois minhas partições já existem, 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 como se fosse uma sessão Live, para 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.

Notei que o instalador detectou o Mageia e o MX Linux (identificado como Debian) — mas não o Void Linux, que também está no 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).

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 ainda mostra um resumo das partições que serão formatadas. — Ainda dá tempo de perceber algum perigo e voltar atrás, para corrigir.

Alterações no UEFI Boot Menu após a instalação do Fedora 42 no SSD WD Green

Ao reiniciar o computador, notei que o instalador Anaconda havia alterado o bootloader do Fedora 41 — depois de criar o bootloader do Fedora 42!

efibootmgr

No entanto, o efibootmgr indicou que a prioridade de boot era do Fedora 42.

Configuração

Redução do uso de RAM do Fedora 42, após desabilitar serviços que não uso

xxxx

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.