Vou testar por aqui…
Guilherme, agora você fez a pergunta de 0,49 dólares… ![]()
Existem dúzias de “fetch” – e isso não é de hoje! – Tenho monitorado apenas o “velho e bom” screenFetch (mantenedor ativo, sempre atualizando) – e o Neofetch, por ser o que milhares de usuários gostam de exibir nas redes sociais, tipo, “olha como minha distro usa pouca RAM”. ![]()
Ouvi falar muito do “Fastfetch”, na última semana, mas ainda é cedo para saber se irá se tornar o novo “queridinho” dos milhões de usuários que gostam de alardear que suas distros usam pouca RAM.
Se o Fastfetch se tornar tendência universal, talvez eu passe a monitorá-lo. – Mas por enquanto, a roleta está só começando a girar. – Vamos ver em qual “fetch” ela irá se fixar.
Aproveitei para atualizar meu “monitoramento de ferramentas de monitorar uso de RAM”.
Percebi que o htop abandonou o “cálculo muito antigo” – e voltou para o “cálculo antigo” – que usava antes.
Infelizmente, olhando o “changelog” do htop, não consegui entender em qual versão isso mudou.
O que achei ruim é que no Ubuntu a única maneira de instalar ele é adicionando um ppa.
Fiz um em shell script depois que vi a notícia desse tópico. Sei que ainda da para usar o neofetch tranquilamente, mas confesso que achei legal fazer o script. Falta só uma imagem ASCII
.
Eu no Mint Cinnamon, e o screenfetch “informando” que meu DE é GNOME, hahahahahahaha
Curioso kkk
Eu peguei o fastfetch, só não curtir ele dar o ip por padrão. Informações potencialmente sensíveis não deveriam ser exibidas por padrão.
Depois vou ver como edita isso.
De resto ele incomparavelmente mais rápido mesmo e achei bom mostrar o uso de disco. O arch não puxa nada que mostre essa informação facilmente quando você instala o cinnamon então poupa o trabalho de usar df
O IP local não tem importância, ele só é usado dentro da sua rede.
Parece porque o neowofetch é na verdade uma continuação do neofetch, é literalmente o mesmo código com uns patches que ficaram em aberto e o autor nunca tempo de conferir (tem até um meu no balaio de gato).
Infelizmente o código para usar o novo cálculo foi adicionado pouco antes de se parar de lançar novas versões…
(Por curiosidade, fui olhar no fastfetch e adicionaram o cálculo com MemAvailable no começo desse ano – infelizmente quem quer forjar um número baixo vai ter que caçar em outro lugar).
Eu diria… “felizmente”… ![]()
Instalei do AUR e recolhi os números 10 minutos uptime:
Vou deixar só no Arch, por enquanto.
Muito show!
Instalei aqui no meu Ubuntu WSL.
Fiz uns testes, só com:
- screenFetch
- Neofetch
- Fastfetch
- Neowofetch
hyfetch
Em velocidade, o Fastetch vence todos os outros, por 10 x 0 – enquanto o Neowofetch / hyfetch cai para a 3ª ou 4ª divisão do campeonato:
Além disso, o screenFetch é mais devagar no Debian, do que no Arch.
Coloquei o Neowofetch no script que reúne as informações de várias ferramentas sobre o uso de Memória RAM, 10 minutos após o boot – e com isso o script passou a demorar 2 ou 3 segundos para ser executado – enquanto, antes, levava só 1 segundo:
Também notei que as ferramentas executadas depois do Neowofetch são afetadas por ele: – Passaram a indicar números um pouco maiores:
Para isso, a solução seria executar o Neowofetch depois de todas as outras ferramentas.
Na verdade, o melhor é nem usar. – Eu só coletava dados do screenFetch e do Neofetch para monitorar o comportamento deles. – Para saber o uso de Memória RAM, basta subtrair MemTotal - MemAvailable (disponíveis em /proc/meminfo). O “cálculo novo” proposto desde 2014 (Kernel 3.14).
Quanto às informações que cada um oferece:
screenFetch
Neofetch
Fastfetch
… ou, sem corte – considerando que tenho um monte de partições:
Neowofetch
Quando se clica no link do Neowofetch, que aparece no Synaptic, vai direto para o site do hyfetch – o que passa a impressão de serem uma coisa só, ou um desenvolvimento compartilhado. – Ambos pretendem ser uma retomada do desenvolvimento do Neofetch. E de fato, ambos implementaram o “cálculo novo” do uso de Memória RAM.
hyfetch
A diferença mais óbvia, é que o hyfetch é para o usuário que deseja exibir também sua opção sexual – a escolher, entre 122 tons do arco-íris. ![]()
Mas tanto o Neowofetch quanto o hyfetch falham miseravelmente, ao tentar exibir as versões do Frameworks e do Qt – coisa que só eles tentam fazer.
Na real, há uma “transição”, onde o Plasma 6 ainda mantém muitos pacotes do Kf5 e do Qt5:
Também achei estranho o hyfetch dizer que tenho 6 pacotes “npm” instalados. – Instalei apenas 1, explicitamente pelo comando npm, mas, vai saber! – Acho mais provável ter 6 pacotes do AUR, que o hyfetch não cita.
Por enquanto, examinei apenas os repositórios oficiais do Debian, KDE Neon, MX Linux e PCLinuxOS – mais fáceis de explocar, via Synaptic – e deixei de lado o cpuFetch:
Apenas no Arch Linux, recorri ao AUR para instalar o Fastfetch, no dia 5 – e apenas 2 dias depois, já apareceu uma versão mais nova no repositório oficial:
# date; pacman -Syyu; date
Tue 7 May 20:20:02 -03 2024
...
Packages (19) fastfetch-2.11.5-1
...
O Neowofetch parece retomar a sequência das versões do Neofetch:
- Neofetch 7.1.0
- Neowofetch 7.3.11
enquanto o hyfetch iniciou outra numeração – o que talvez dificulte verificar até que ponto serão “a mesma coisa” (com visuais diferentes) ou não:
- hyfetch 1.4.11
Ainda não verifiquei os repositórios do openSUSE Tumbleweed, Fedora, Mageia, Slackware, Void, Manjaro, Redcore.
Afinal, não costumo usar nenhum “fetch”. – Apenas, monitorava o screenFetch e o Neofetch, para saber como estavam se comportando.
Tenho a impressão de que o Fastfetch vai tomar conta da praia – tanto por ser rápido, quanto por oferecer muitas possibilidades de configuração. – Talvez troque o screenFetch e o Neofetch por ele, desde que ele apareça nos repositórios oficiais ou semi-oficiais de todas as distros.
Mas esse monitoramento, agora, só se justifica pela teimosia do htop – que já adotou o “cálculo novo” – depois regrediu para o “cálculo muito antigo” – e agora voltou para o “cálculo antigo” (que usava antes).
Parabéns pela apresentação detalhada.
Vai ser útil para o pessoal escolher.
Como não tenho feitiche por tantos “fetchs”, ficarei com o Fastfetch, mesmo.
Obs: Ainda bem que o seu computador não tem muitas partições… ![]()
Acho que não tem muito que escolher…
Por toda parte, há uma clara preferência pelo Fastfetch – e depois dessa pesquisa, acho que essa maioria está mais do que certa: – É rápido, é completo, é bem configurável.
Antes de ficar reiniciando o PC, carregando uma distro após outra, procurar etc. – resolvi pesquisar logo o Fastfetch no Repology e no PKGs.
Segundo o PKGs:
-
O Arch aparece isolado, com a versão 2.11.5 no repositório oficial.
-
Fedora 40 está no 2.8 ou 2.9. – Fedora Updates Testing e Fedora Rawhide já têm o 2.11.5.
-
OpenMandriva está no 2.9. – OpenMandriva Cooker tem o 2.11.5.
-
openSUSE Tumbleweed tem o 2.11.0.
O Repology tem mais indicações do Fastfetch 2.11.5:
- Arch
- Fedora Rawhide
- Manjaro Testing e Unstable
- OpenMandriva Cooker
enquanto:
- openSUSE Tumbleweed tem 2.11.0
- SlackBuilds tem 2.10.2
- Solus tem 2.11.2
Naturalmente, deve haver várias opções, entre Flatpak, Snapd, AppImage, npm, pipo, Git etc., mas não tenho tanta pressa.
Não conhecia o Repology. ![]()
Fastfetch 2.11.0 no openSUSE Tumbleweed:
Me impressiona como tudo é mais demorado! – Neofetch leva 0,5 segundo no Arch e no Debian, e aqui leva quase 2 segundos. – screenFetch leva 1 segundo a 1,4 segundo neles, e aqui demora de 2,1 a 2,4 segundos.
Até o Fastfetch quase dobrou o tempo – de 0,13 ou 0,14 para 0,23 a 0,26 segundo.
*orientação ![]()
Não conhecia esse cara. Instalei aqui e achei bem interessante.
Aliás, fazia tanto tempo que não usava o Neofetch… Nem sabia que havia sido descontinuado. rsrsrs
Devo estar em outro mundo. ![]()
Sim, sim…
Pisei na bola, he he.
Estou fazendo um levantamento dos “fetch” mais falados etc. — falta apresentar 2, dos 14 ou 15 que instalei no Arch.
- No Void encontrei o “ufetch” — tão “simples” quanto o “pfetch”. — A diferença é que o pfetch dá um número do “uso de Memória RAM”… e o ufetch, não.
Aproveitei que meu Void “ressuscitou”, para tentar encontrar e instalar mais algumas ferramentas “fetch” — mas percebi que os recursos “tradicionais” do Void não oferecem um campo tão amplo quanto o Arch Linux.
Daí, meu “interesse renovado” no Redcore (Gentoo). – De repente, me dei conta que “a alternativa ao Arch que também tem de tudo” não é o Void. — É o Redcore.

















