 |
| 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 |
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
- Sem cálculo
- Arquivados
- 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.
