 |
| Comando free assusta testadores do Debian 12 Bookworm RC, em Abril 2023 |
• Usuários que executaram o comando free para medir o uso inicial de Memória RAM do Debian 12 Bookworm RC, em Abril 2023, levaram um susto: — Quase o dobro do que o free indicava no Debian 11!
Não foi o Debian que mudou. — O que mudou foram as ferramentas free / top, do pacote procps 4.0 — mas isso já vinha ocorrendo com outras ferramentas, pelo menos desde 2020.
Trata-se de um “cálculo novo” — proposto por Linus Torvalds em 2014 — e que só a partir de 2020 começou a ser adotado pelas principais ferramentas, cada uma em um momento diferente:
/proc/meminfo --> (New calc):
Mem used = MemTotal - MemAvailable
- ver “Agosto 2020”, adiante.
Vale a pena registrar essas mudanças — bem como as divergências de muitos usuários e desenvolvedores — e os erros de comparação que se cometem a cada dia, pelo uso de ferramentas com cálculos diferentes.
Índice
- 2017 a 2020
- Agosto 2020
- Março 2021
- Maio 2021
- Outubro 2021
- Abril 2023
- Natal 2023
- Abril 2024
- Existe vida após o Neofetch
- Comparar distros?
- Ferramentas e medições
- No Conky
- Em TXT
- Referências
- Aplicativos GUI
- KSysguard
- Terminais
- Plasma System Monitor
- Gnome System Monitor
2017 a 2020
 |
| Paridade de cálculo de uso de Memória RAM, entre Conky e htop, em 2017 |
Desde 2017, notei que o Conky e o htop indicavam números quase iguais de uso de Memória RAM. — Em meados daquele ano fiz dezenas de testes, em várias distros, e comprovei aquela paridade — exceto no openSUSE Leap, cujo Conky recebia atualizações em ritmo frenético, e sempre discrepava do htop.
- O Quadro (acima) é um resumo. Números detalhados estão em “Paridade-RAM-Conky-htop-2017-2020”.
Aquele cálculo — que chamo de “cálculo antigo”, para facilitar — seguia esta fórmula (aproximadamente), a partir dos dados em /proc/meminfo:
/proc/meminfo --> (Old calc):
Mem used = MemTotal - [MemFree + Active(file) + Inactive(file) + SReclaimable]
O arquivo /proc/meminfo contém dezenas de informações acessíveis ao usuário comum — atualizadas o tempo todo — incluindo estas:
$ cat /proc/meminfo | wc --lines
56
$ cat /proc/meminfo | grep 'Mem\|Active\|Inactive\|Reclaimable'
MemTotal: 16222988 kB
MemFree: 9512728 kB
MemAvailable: 11838260 kB
Active: 4013088 kB
Inactive: 1410380 kB
Active(anon): 3098724 kB
Inactive(anon): 0 kB
Active(file): 914364 kB
Inactive(file): 1410380 kB
KReclaimable: 341236 kB
SReclaimable: 341236 kB
Também notei, naquela época, que as ferramentas free e top (do procps) davam números bem menores — como nesse registro de 2019:
 |
| Divergência do free e do top em relação ao Conky e ao htop, em 2019 |
Como meu interesse era só no Conky, nunca pesquisei a fórmula usada naquela época pelo free e pelo top — que vou chamar de “cálculo muito antigo” (se me permitirem), só para facilitar a comunicação.
O inxi tinha um cálculo próprio, só dele — que também não pesquisei.
Agosto 2020
 |
| Aumento aparente de uso de RAM, com o Conky 1.11.6 |
Desde Agosto 2020, o Conky 1.11.6 passou a mostrar valores bem mais altos de uso de Memória RAM — no openSUSE Tumbleweed, Debian testing, Fedora, Mageia 8 (beta), Void Linux. — Foi o “primeiro susto”, digamos assim.
 |
| Proposta do “novo cálculo”, em 2014 |
Não era bug. — Era uma “correção” do cálculo da “Memória RAM usada” — proposta ou subscrita por Linus Torvalds desde Janeiro 2014 (Kernel 3.14), quando se introduziu em /proc/meminfo um campo “MemAvailable”, exatamente para tornar esse cálculo mais acurado:
Currently, the amount of memory that is available for a new workload, without pushing the system into swap, can be estimated from MemFree, Active(file), Inactive(file), and SReclaimable, as well as the "low" watermarks from /proc/zoneinfo.
However, this may change in the future, and user space really should not be expected to know kernel internals to come up with an estimate for the amount of free memory.
It is more convenient to provide such an estimate in /proc/meminfo. If things change in the future, we only have to change it in one place.
 |
| Aplicação do “novo cálculo” ao Conky, em 2019 |
A aplicação dessa mudança no Conky só foi pedida em Junho 2019; — efetuada em Outubro 2019 (acima); — e ainda demorou 10 meses, até o Conky 1.11.6 chegar às principais distros rolling-release (e ao Fedora).
Foi o marco inicial de um movimento (bem atrasado) para um cálculo tecnicamente mais correto — além de bem mais simples e fácil.
Março 2021
 |
| Situação após nova reviravolta do Conky |
Em Março 2021, o Conky 1.12.1 fez uma reviravolta, — passando a exibir valores muito baixos.
Foi uma rendição (temporária, felizmente) à grita de usuários, que exigiam paridade do Conky com o free / top — no que apelidei de “cálculo muito antigo” (se os experts permitirem). — No fundo, uma ânsia de garantir o troféu de “mais leve” para suas distros.
Com o tempo, no entanto, foi-se delineando um movimento de outras ferramentas rumo ao “cálculo novo” — embora com recuos aqui e ali:
Maio 2021
 |
| Uso de Memória RAM segundo várias ferramentas, em Maio 2021 |
Em Maio 2021, tabulei esse registro (acima) do suposto uso inicial de Memória RAM das distros que eu tinha naquele momento (todas com KDE), para ver o estado das ferramentas naquele momento:
- “cálculo novo”
- “cálculo antigo”
- “cálculo muito antigo”
- cálculo específico do inxi
Era o auge das idas-e-vindas do Conky — que chegou a ter pelo menos 4 versões na praça, brigando umas com as outras:
Conky 1.10.8 = htop (old calc) Neon, Mint 20, MX Linux 19
Conky 1.11.6 > htop (new calc) Arch, Debian testing, Mageia 8
Conky 1.12.1 < htop (very old calc) Fedora 33, PCLinuxOS, Void
Conky 1.12.2 > htop (new calc) openSUSE Tumbleweed
 |
| Uso de Memória RAM segundo várias ferramentas, em Maio 2021 |
Acima: - A tabulação permitiu verificar a faixa de variação do “cálculo antigo” em -24% a -34% dos valores indicados pelo “cálculo novo” — e o “cálculo muito antigo” numa faixa de -39% a -56% — enquanto versões anteriores do inxi tinham um cálculo próprio, só dele, na faixa de -37% a -39%.
 |
| Uso de Memória RAM segundo várias ferramentas, em Maio 2021 |
Esse levantamento também facilitou identificar as versões de cada ferramenta, com os diferentes cálculos de uso de Memória RAM:
- O inxi já tinha adotado o “cálculo novo”, pelo menos desde sua versão 3.1.00 (2020-11-11) — mas ainda sobreviviam versões anteriores no KDE Neon e no Linux Mint 20 (base: Ubuntu LTS); e no MX Linux 19 (base: Debian stable 10 ”Buster”).
- O screenFetch também já tinha adotado o “cálculo novo”, mas não sei exatamente quando. — A versão 3.8.0 (MX Linux 19) ainda mostrava o mesmo valor indicado por free / top — mas o Changelog das versões seguintes (3.9.0, 3.9.1) não registrou essa mudança.
- O htop permanecia com seu tradicional “cálculo antigo”
- O Neofetch permanecia no “cálculo antigo” — exceto no Slackware, apesar de ser a mesma versão (7.1.0) das outras distros. — Imagino que fosse uma personalização feita pela equipe da distro.
- free / top continuavam com o “cálculo muito antigo”
Outubro 2021
 |
| Conky, htop, inxi e screenFetch com o “cálculo novo”, Outubro 2021 |
Até Outubro 2021, outra mudança:
- O htop (3.1.0) adotou o “cálculo novo” em 2021-09-21 — e cheguei a ver isso no Arch, no Manjaro, no openSUSE Tumbleweed, no Void — mas foi um fenômeno de curta duração, pois logo se renderia à grita dos usuários, exigindo paridade com o “cálculo muito antigo” do free / top. — Fica o “registro histórico” desse raro momento.
Abril 2023
 |
| Uso de RAM, segundo diferentes ferramentas (3 amostras, Abril 2023) |
Em Abril 2023 (acima), continuávamos longe de uma padronização no cálculo de uso de Memória RAM — mas 3 ferramentas já usavam o “cálculo novo”, em todas as versões das minhas distros: — Conky, inxi e screenFetch.
- O MX Linux utilizava uma versão personalizada do inxi — adaptada para fornecer informações em seu Fórum — e que não consegui acionar pelos comandos comuns às outras distros.
 |
| Uso de RAM, segundo diferentes ferramentas (3 amostras, Abril 2023) |
Além disso, o pacote procps 4.0 anunciava a adesão do free / top ao “cálculo novo”, no Debian testing.
 |
| Uso de RAM, segundo diferentes ferramentas (3 amostras, Abril 2023) |
Na verdade, o procps 4.0 adotou o “cálculo novo” em 2022-06-24 — e já tinha chegado ao Debian testing por volta do Natal:
procps (2:4.0.2-1) unstable; urgency=medium * free: Used memory is Total - Available This means versions of free after 4.0.0 will show different Used values for older frees and some other system utilities. -- Craig Small [csmall@debian.org] Mon, 05 Dec 2022 21:34:57 +1100
Enfim, desde Junho 2022, o openSUSE Tumbleweed já tinha alterado seu free / top 3.3.17 para o “cálculo novo” — sem esperar a versão 4.0.
Na contra-mão desse movimento geral, a versão 3.1.1 (2021-10-14) do htop cedeu à grita dos usuários e retrocedeu para o “cálculo muito antigo” — mas em algumas distros (KDE Neon, Mageia 8, MX Linux 21) ainda sobrevivia o htop 3.0.5, com o “cálculo antigo”.
Portanto, quando o htop recuou para o “cálculo muito antigo” — o free / top já se movimentava para o “cálculo novo”.
Natal 2023
 |
| Uso de Memória RAM segundo várias ferramentas, no Natal 2023 |
Com o rápido avanço das distros para o pacote procps 4.0, desenha-se para breve um quadro — em que apenas o Neofetch e o htop insistirão em manter o “cálculo antigo” e o “muito antigo”, respectivamente.
 |
| Uso de Memória RAM segundo várias ferramentas, no Natal 2023 |
Em 8 das minhas 12 distros (*), free / top já usam o “cálculo novo” — e esse número talvez fosse maior, se eu atualizasse o Slackware e o Redcore. — Restam o KDE Neon (base: Ubuntu LTS) e o PCLinuxOS.
(*) Considero o KDE Neon User Edition e o KDE Neon Unstable como 1 só distro, pois a base é a mesma (Ubuntu LTS 22.04), mudando só a versão do KDE.
 |
| Uso de Memória RAM segundo várias ferramentas, no Natal 2023 |
Dentro de alguns meses, portanto, prevejo 5 ferramentas com o “cálculo novo” em todas as minhas distros — e apenas Neofetch e htop com cálculos diferentes.
Abril 2024
 |
| Neofetch descontinuado, após quase 4 anos sem manutenção |
26 Abril 2024 - O repositório do Neofetch no Github foi arquivado por seu proprietário, tornando-se “read-only”. — Uma mensagem no seu perfil (Have taken up farming) sugere uma mudança de vida.
A última versão lançada é a 7.1.0, de 2 Agosto 2020. — Ficaram 293 “problemas” (issues) em aberto — e 198 pedidos não atentidos.
 |
| Uso de Memória RAM segundo várias ferramentas, em Abril 2024 |
Só então, percebi que o htop tinha mudado — mais uma vez! — De volta para o “cálculo antigo”, que usava no período 2017-2020 (pelo menos).
Infelizmente, ainda não consegui perceber, no changelog do htop, em qual versão aconteceu essa reviravolta.
 |
| Uso de Memória RAM segundo várias ferramentas, em Abril 2024 |
Retirei desse monitoramento as distros que não estou atualizando — o KDE Neon “Plasma 5”, o Slackware e o Redcore — e com isso, ficou mais nítido o avanço dessas ferramentas rumo à padronização do cálculo de Memória RAM usada.
 |
| Uso de Memória RAM segundo várias ferramentas, em Abril 2024 |
É impossível prever quando o Neofetch começará a “desaparecer” — afinal, ele continua funcionando, pelo menos na aparência — e a inércia é um dos atributos da liberdade, que nos permite dispor de centenas de distribuições Linux.
Existe vida após o Neofetch
 |
| Uso de RAM, segundo ferramentas “fetch” que usam o “cálculo novo” — ou não |
Não costumo fazer capturas de tela com ferramentas “fetch” para provar que “meu Arch é mais leve, BTW” — até porque sei que não é. — Meu interesse é monitorar o comportamento das ferramentas mais usadas nos fóruns, grupos, comunidades, para exibir o “uso de Memória RAM”.
O arquivamento do Neofetch chamou atenção para as alternativas — e tudo indica que o Fastfetch tende a ser a mais popular — por ser super-rápido, exibir o máximo de informações, e ser altamente configurável. — E felizmente, usa o “cálculo novo”.
 |
| Nas distros que oferecem o Fastfetch, retirei o screenFetch e o Neofetch |
Não faz sentido encher o Conky com dados de uso de Memória RAM de uma dúzia de ferramentas que ninguém usa. — Por isso, deixei só o Fastfetch nas distros em cujos repositórios ele já está presente — e nas outras, mantive o screenFetch e o Neofetch, que ainda estão presentes no maior número de repositórios.
Comparar distros?
 |
| Uso inicial de Memória RAM, pelo cálculo “MemTotal - MemAvailable” |
A meu ver, comparações entre diferentes distros Linux só fazem sentido, se todos utilizarem o mesmo “cálculo” — e o mesmo DE. — E qualquer comparação entre diferentes DEs só faz sentido, quando se usa a mesma distro e o mesmo cálculo.
Usando KDE Plasma, há muito tempo me dei conta de que minhas distros mais “leves” costumavam ser o Void, o PCLinuxOS, o Slackware e o Redcore (Gentoo). — Eu poderia ser tentado a dizer “distros sem-SystemD” — caso o Manjaro não se intrometesse no meio — e MX Linux não estivesse, hoje, na “3ª divisão”, das distros que mais usam Memória RAM.
No 2º grupo, “intermediário”, estão o Arch (onde instalei só o que preciso; e o Manjaro); — o Mageia Cauldron (do qual eliminei tudo que pude); — e o KDE Neon (que sempre foi mais “enxuto” do que o Kubuntu padrão).
Ora, no 1º grupo, o Void também é uma instalação “enxuta” — assim como o PCLinuxOS Darkstar. — A ausência de “inchaço” (bloat), me parece a melhor explicação para o menor uso de Memória RAM (com ou sem SystemD).
Em contrapartida, o “inchaço” (bloat) do openSUSE e do Fedora parece valer cada byte utilizado — pelo que acrescenta de vantagens para o usuário — embora nem sempre eu queira todas essas “vantagens”.
Enfim, o gráfico (acima) foi feito a partir de 1 única amostragem. — Isso poderia ser diferente, numa média de 3+ amostragens, pois os números costumam variar, de um boot para outro (e também, a cada segundo).
Ferramentas e medições
 |
| Monitorando as ferramentas pelo Conky |
À medida em que o Conky e as demais ferramentas entravam nessa fase de mudanças — e seus números perdiam consistência entre as distros — adotei o “cálculo novo”, feito por meus próprios scripts.
No Conky
 |
| Calculando o uso de RAM para monitorar as ferramentas |
Optei por exibir esse “cálculo novo” no meu Conky2 — encabeçando os números das demais ferramentas — para consultá-los ao vivo — e deixá-los documentados nas Capturas de tela:
conky.config = {
(...)
update_interval = 10,
(...)
}
conky.text = [[
Mem: ${alignr 100}up ${uptime}
Total - Available ${alignr 100}${exec bash MemInfo.sh; cat MemInfo.txt}
Conky (Mem) ${alignr 100}${mem}
free ${alignr 100}${exec free -m | grep Mem | cut -c 25-35} MiB
top ${alignr 100}${exec top -E m -b -n 1 | grep buff | cut -c 41-50} MiB
neofetch ${alignr 100}${exec neofetch --stdout | grep -o -P '.{0,0}Memory.{0,9}' | cut -b 8-12} MiB
htop ${alignr 100}${exec export TERM=xterm; echo q | htop | aha --line-fix | html2text | grep -o -P '.{0,6}/15' | cut -b 1-6}iB
inxi ${alignr 100}${exec inxi --memory-short | grep -o -P '.{0,0}used.{0,14}' | cut -b 6-14}
screenfetch ${alignr 100}${exec screenfetch -n -N | grep -o -P '.{0,0}RAM.{0,9}' | cut -b 5-12}
(...)
${alignr}${cat done.txt} ${execi 600 echo $XDG_SESSION_TYPE}
(...)
]]
Na linha “Total - Available” (acima), o Conky executa um script “MemInfo.sh” — que efetua o “cálculo novo” — e salva o resultado em um arquivo “MemInfo.txt”:
MEM_TOTAL=$(awk '/MemTotal/ { printf $2 }' /proc/meminfo); \
MEM_AVAIL=$(awk '/MemAvailable/ { printf $2 }' /proc/meminfo); \
MEM_USED_KILO="$(($MEM_TOTAL-$MEM_AVAIL))"; \
echo "$(($MEM_USED_KILO/1024))" MiB > MemInfo.txt
O ciclo de 10 segundos do “Conky2” evita oscilações contínuas — de modo que o gnome-screenshot ou o KDE Spectacle não capturem um valor já afetado por seu próprio acionamento (+ 25 ~ 40 MiB durante uns 25 segundos).
Em TXT
Também criei um script “RAM.sh” — que salva essas informações em um arquivo “RAM_00-Distro.txt”, 10 minutos após o boot. — Para registrá-las, basta reiniciar o computador e ir tomar um café:
echo "------------------------------------------------------------------" > RAM_02-Arch.txt
date >> RAM_02-Arch.txt
echo "-------------------- uptime ----------------------------------" >> RAM_02-Arch.txt
uptime -p >> RAM_02-Arch.txt
uptime -s >> RAM_02-Arch.txt
echo "----------------- MemTotal - MemAvailable --------------------" >> RAM_02-Arch.txt
MEM_TOTAL=$(awk '/MemTotal/ { printf $2 }' /proc/meminfo);\
MEM_AVAIL=$(awk '/MemAvailable/ { printf $2 }' /proc/meminfo);\
MEM_USED_KILO="$(($MEM_TOTAL-$MEM_AVAIL))";\
MEM_USED_BYTES_X_1000="$(($MEM_USED_KILO*1000))";\
echo "$(($MEM_USED_KILO/1024))" MiB >> RAM_02-Arch.txt
echo "$(($MEM_USED_BYTES_X_1000/1048576))" MiB, exactly >> RAM_02-Arch.txt
echo "-------------------- Conky ----------------------------------" >> RAM_02-Arch.txt
conky -c ~/.config/conky/conky3.conf
cat Conky.txt >> RAM_02-Arch.txt
echo "--------------------- free -----------------------------------" >> RAM_02-Arch.txt
free -m >> RAM_02-Arch.txt
echo "--------------------- top -----------------------------------" >> RAM_02-Arch.txt
top -E m -b -n 1 | grep buff >> RAM_02-Arch.txt
echo "--------------------- neofetch -----------------------------------" >> RAM_02-Arch.txt
neofetch --stdout | grep "Memory" >> RAM_02-Arch.txt
echo "--------------------- htop -----------------------------------" >> RAM_02-Arch.txt
export TERM=xterm; echo q | htop | aha --line-fix | html2text | grep "/15" >> RAM_02-Arch.txt
# export TERM=xterm; echo q | htop >> RAM_02-Arch.txt
echo "--------------------- inxi -----------------------------------" >> RAM_02-Arch.txt
inxi -m >> RAM_02-Arch.txt
echo "------------------- screenfetch ----------------------------------" >> RAM_02-Arch.txt
screenfetch -n -N -E | grep "RAM" >> RAM_02-Arch.txt
echo "------------------------------------------------------------------" >> RAM_02-Arch.txt
date >> RAM_02-Arch.txt
echo "------------------------------------------------------------------" >> RAM_02-Arch.txt
echo '•' > done.txt
Acima - Para salvar em arquivo a variável mem do Conky, o script executa o Conky3 — apenas 1 vez (total_run_times = 1). — Encontrei essa dica de 2011 no Linux Questions e atualizei a sintaxe (out_to_x = false):
conky.config = {
out_to_x = false,
out_to_console = false,
out_to_stderr = false,
own_window = no,
extra_newline = false,
uppercase = no,
overwrite_file = 'Conky.txt',
no_buffers = yes,
double_buffer = false,
total_run_times = 1,
}
conky.text = [[
Conky (Mem) ${mem}
]]
No final, o bash script cria um arquivo “done.txt” com um bullet “•”, que o Conky2 exibe à esquerda do indicador X11 / Wayland — e depois disso, já posso começar a usar a máquina:
 |
| Calculando o uso de RAM para monitorar as ferramentas |
O bullet “•” permanece à esquerda do indicador X11 / Wayland por 3 minutos (até 13 minutos uptime) — quando é apagado por outro script: — “VERSIONS.sh”.
Este segundo script apenas adiciona ao arquivo “RAM_00-Distro.txt” as versões da distro, do Kernel, do init, do KDE e das ferramentas. — Em seguida, move o arquivo para uma pasta comum a todas as distros — e por fim, torna a esvaziar o arquivo “done.txt”, eliminando assim o bullet “•”:
echo '------- Versions -----------' >> RAM_02-Arch.txt
echo '------------------------------' >> RAM_02-Arch.txt
date >> RAM_02-Arch.txt
echo '------------------------------' >> RAM_02-Arch.txt
uname -n >> RAM_02-Arch.txt
lsb_release -ds >> RAM_02-Arch.txt
uname -sr >> RAM_02-Arch.txt
strings /sbin/init | awk 'match($0, /(upstart|systemd|sysvinit|busybox|runit|openrc|S6|66-boot)/) { print substr($0, RSTART, RLENGTH);exit; }'\
>> RAM_02-Arch.txt
systemctl --version | grep systemd | cut -c 9-11 >> RAM_02-Arch.txt
#rc-service -V >> RAM_02-Arch.txt
echo '------------------------------' >> RAM_02-Arch.txt
plasmashell --version >> RAM_02-Arch.txt
neofetch --de_version on --stdout | grep "DE:" >> RAM_02-Arch.txt
kf5-config --version | grep 'Qt\|KDE' >> RAM_02-Arch.txt
echo '------------------------------' >> RAM_02-Arch.txt
konsole -v >> RAM_02-Arch.txt
kate -v >> RAM_02-Arch.txt
dolphin -v >> RAM_02-Arch.txt
gwenview -v >> RAM_02-Arch.txt
echo '------------------------------' >> RAM_02-Arch.txt
gimp --version >> RAM_02-Arch.txt
google-chrome-stable --version >> RAM_02-Arch.txt
libreoffice --version >> RAM_02-Arch.txt
echo '------------------------------' >> RAM_02-Arch.txt
conky -v | grep compiled >> RAM_02-Arch.txt
free -V >> RAM_02-Arch.txt
top -v | grep procps >> RAM_02-Arch.txt
neofetch --version >> RAM_02-Arch.txt
htop --version >> RAM_02-Arch.txt
inxi -V | grep inxi >> RAM_02-Arch.txt
screenfetch -V | grep Version >> RAM_02-Arch.txt
echo '------------------------------' >> RAM_02-Arch.txt
date >> RAM_02-Arch.txt
echo '------------------------------' >> RAM_02-Arch.txt
mv RAM_02-Arch.txt /run/media/flavio/Warehouse/Byteria/Conky/Conky-RAM-New/
echo ' ' > done.txt
Uso um comando padronizado para detectar o software init — e outros comandos, “caso-a-caso”, para obter a versão de cada init. — Apenas no Void, ainda não descobri como exibir a versão do runit:
[PATH]/Conky/backup/2022-07-18
$ grep -R -A 2 sysname
openSUSE ${sysname} ${kernel} ${alignr}\
${execi 600 echo $(strings /sbin/init | awk 'match($0, /(upstart|systemd|sysvinit|busybox|runit|openrc|S6|66-boot)/) { print substr($0, RSTART, RLENGTH);exit; }')} \
${execi 600 systemctl --version | grep systemd | cut -c 9-11}
Arch ${sysname} ${kernel} ${alignr}\
${execi 600 echo $(strings /sbin/init | awk 'match($0, /(upstart|systemd|sysvinit|busybox|runit|openrc|S6|66-boot)/) { print substr($0, RSTART, RLENGTH);exit; }')} \
${execi 600 systemctl --version | grep systemd | cut -c 9-11}
Debian ${sysname} ${kernel} ${alignr}\
${execi 600 echo $(strings /sbin/init | awk 'match($0, /(upstart|systemd|sysvinit|busybox|runit|openrc|S6|66-boot)/) { print substr($0, RSTART, RLENGTH);exit; }')} \
${execi 600 systemctl --version | grep systemd | cut -c 9-11}
Fedora ${sysname} ${kernel} ${alignr}\
${execi 600 echo $(strings /sbin/init | awk 'match($0, /(upstart|systemd|sysvinit|busybox|runit|openrc|S6|66-boot)/) { print substr($0, RSTART, RLENGTH);exit; }')} \
${execi 600 systemctl --version | grep systemd | cut -c 9-11}
KDE Neon ${sysname} ${kernel} ${alignr}\
${execi 600 echo $(strings /sbin/init | awk 'match($0, /(upstart|systemd|sysvinit|busybox|runit|openrc|S6|66-boot)/) { print substr($0, RSTART, RLENGTH);exit; }')} \
${execi 600 systemctl --version | grep systemd | cut -c 9-11}
PCLinuxOS Kernel ${sysname} ${kernel} ${alignr}\
${execi 600 echo $(strings /sbin/init | awk 'match($0, /(upstart|systemd|sysvinit|busybox|runit|openrc|S6|66-boot)/) { print substr($0, RSTART, RLENGTH);exit; }')} \
${execi 600 strings /sbin/init | grep INIT_VERSION | cut -c 23-30}
Mageia ${sysname} ${kernel} ${alignr}\
${execi 600 echo $(strings /sbin/init | awk 'match($0, /(upstart|systemd|sysvinit|busybox|runit|openrc|S6|66-boot)/) { print substr($0, RSTART, RLENGTH);exit; }')} \
${execi 600 systemctl --version | grep systemd | cut -c 9-11}
Slackware ${sysname} ${kernel} ${alignr}\
${execi 600 echo $(strings /sbin/init | awk 'match($0, /(upstart|systemd|sysvinit|busybox|runit|openrc|S6|66-boot)/) { print substr($0, RSTART, RLENGTH);exit; }')} \
${execi 600 strings /sbin/init | grep INIT_VERSION | cut -c 23-30}
Void ${sysname} ${kernel} ${alignr}\
${execi 600 echo $(strings /sbin/init | awk 'match($0, /(upstart|systemd|sysvinit|busybox|runit|openrc|S6|66-boot)/) { print substr($0, RSTART, RLENGTH);exit; }')}
Manjaro ${sysname} ${kernel} ${alignr}\
${execi 600 echo $(strings /sbin/init | awk 'match($0, /(upstart|systemd|sysvinit|busybox|runit|openrc|S6|66-boot)/) { print substr($0, RSTART, RLENGTH);exit; }')} \
${execi 600 systemctl --version | grep systemd | cut -c 9-11}
Redcore ${sysname} ${kernel} ${alignr}\
${execi 600 echo $(strings /sbin/init | awk 'match($0, /(upstart|systemd|sysvinit|busybox|runit|openrc|S6|66-boot)/) { print substr($0, RSTART, RLENGTH);exit; }')} \
${execi 600 rc-service -V | cut -c 21-26}
MX Linux ${sysname} ${kernel} ${alignr}\
${execi 600 echo $(strings /sbin/init | awk 'match($0, /(upstart|systemd|sysvinit|busybox|runit|openrc|S6|66-boot)/) { print substr($0, RSTART, RLENGTH);exit; }')} \
${execi 600 strings /sbin/init | grep INIT_VERSION | cut -c 23-30}
É comum eu atualizar algumas distros em 10 minutos, e reiniciar o computador antes da eliminação do bullet. — Para evitar que ele apareça em uma próxima sessão, ele é eliminado logo após um novo boot:
$ crontab -l
@reboot echo ' ' > done.txt
@reboot sleep 600; bash RAM.sh
@reboot sleep 780; bash VERSIONS.sh
Naturalmente, só 2 ou 3 vezes por ano eu me preocupo em esperar 13 minutos após o boot, com o computador “em repouso”, em 12 distros seguidas, para cumprir todos esses passos. — Isso exige mais de 3 horas — e não é frequente eu ver motivo para tanto trabalho.
Nos outros casos, os arquivos abandonados são sobrescritos, e não se acumulam.
 |
| Procurando o uso de Memória RAM do htop |
Os arquivos “RAM_00-Distro.txt” ainda contêm muito lixo — em especial nas distros sem o aha ou o html2text, para o grep salvar uma linha enxuta do htop.
 |
| Extraindo e reunindo os dados de todas as distros |
Além disso, era trabalhoso abrir 12 arquivos “RAM_00-Distro.txt”, um após outro, e garimpar cada informação — então, comecei a desenvolver um script “Summary.sh” — para extrair os dados relevantes e reuni-los em um “Summary.txt”:
### ----------------------------------- ###
### Extracts data from "RAM*.txt" files ###
### ----------------------------------- ###
echo '----------------------------------------' > Summary.txt
echo " ${PWD##*/}" >> Summary.txt
echo '--------------- New Calc ---------------' >> Summary.txt
cat RAM*.txt | grep "MemTotal - MemAvailable" -A1 | grep MiB >> Summary.txt
cat RAM*.txt | grep "MemTotal - MemAvailable" -A1 | grep MiB | wc --lines >> Summary.txt
echo '--------------- Conky ---------------' >> Summary.txt
cat RAM*.txt | grep "Conky (Mem)" >> Summary.txt
cat RAM*.txt | grep "Conky (Mem)" | wc --lines >> Summary.txt
echo '--------------- free ---------------' >> Summary.txt
cat RAM*.txt | grep "shared" -A1 >> Summary.txt
cat RAM*.txt | grep "shared" -A1 | wc --lines >> Summary.txt
echo ' -------> 3 * 13 = 39 - 1 separador a menos' >> Summary.txt
echo '--------------- top ---------------' >> Summary.txt
cat RAM*.txt | grep " top" -A1 | grep "buff/cache" >> Summary.txt
cat RAM*.txt | grep " top" -A1 | grep "buff/cache" | wc --lines >> Summary.txt
echo '--------------- Neofetch ---------------' >> Summary.txt
cat RAM*.txt | grep "Memory: " >> Summary.txt
cat RAM*.txt | grep "Memory: " | wc --lines >> Summary.txt
echo '--------------- htop ---------------' >> Summary.txt
grep -E -o ".{0,10}15.5G.{0,1}" RAM*txt >> Summary.txt
grep -E -o ".{0,10}15.5G.{0,1}" RAM*txt | wc --lines >> Summary.txt
echo '--------------- inxi ---------------' >> Summary.txt
cat RAM*.txt | grep " inxi " -A2 | grep used >> Summary.txt
cat RAM*.txt | grep " inxi " -A2 | grep used | wc --lines >> Summary.txt
echo '--------------- screenFetch ---------------' >> Summary.txt
cat RAM*.txt | grep " screenfetch " -A1 | grep RAM >> Summary.txt
cat RAM*.txt | grep " screenfetch " -A1 | grep RAM | wc --lines >> Summary.txt
echo ' 09 ----- Void has not -----' >> Summary.txt
echo '--------------- Versions ---------------' >> Summary.txt
echo '--------------- Conky ---------------' >> Summary.txt
cat RAM*.txt | grep "compiled" >> Summary.txt
cat RAM*.txt | grep "compiled" | wc --lines >> Summary.txt
echo '--------------- procps ---------------' >> Summary.txt
cat RAM*.txt | grep "free from" >> Summary.txt
cat RAM*.txt | grep "free from" | wc --lines >> Summary.txt
echo '--------------- Neofetch ---------------' >> Summary.txt
cat RAM*.txt | grep "Neofetch " >> Summary.txt
cat RAM*.txt | grep "Neofetch " | wc --lines >> Summary.txt
echo '--------------- htop ---------------' >> Summary.txt
cat RAM*.txt | grep "htop 3" >> Summary.txt
cat RAM*.txt | grep "htop 3" | wc --lines >> Summary.txt
echo '--------------- inxi ---------------' >> Summary.txt
cat RAM*.txt | grep "inxi 3" >> Summary.txt
cat RAM*.txt | grep "inxi 3" | wc --lines >> Summary.txt
echo '--------------- screenFetch ---------------' >> Summary.txt
cat RAM*.txt | grep "screenFetch" >> Summary.txt
cat RAM*.txt | grep "screenFetch" | wc --lines >> Summary.txt
echo ' 09 ----- Void has not -----' >> Summary.txt
echo '-------------------------------------------' >> Summary.txt
Ao reunir os dados de cada ferramenta, aproveito para contar o número de linhas encontradas — para conferir se falta alguma coisa — e inserir um lembrete de que o Void, por exemplo, ainda está sem screenFetch.
 |
| Uso do “Modo de Seleção de Blocos” do Kate / KWrite |
Ainda está muito longe de uma “automação total”, mas já facilita para organizar os números em colunas — e copiá-las para uma planilha — pelo “Modo de Seleção de Blocos” do Kate / KWrite.
Referências:
- htop output to human readable file
- htop and crontab
- Is it correct to set the $TERM variable manually?
- Kilobyte
Aplicativos GUI
KSysguard
 |
| KSysguard indica menos do que o “cálculo muito antigo” |
O nome genérico “Monitor do Sistema” tem induzido a muitos enganos e falsas comparações — pelo menos desde 2016, quando tive o KSysguard e o Gnome System Monitor lado a lado, em um Debian com vários ambientes.
Desde aquela época, verifiquei que o KSysguard indicava uso de Memória bem inferior ao indicado pelo Conky — ainda com o “cálculo antigo”.
Me parece que o KSysguard utiliza o “cálculo muito antigo” do free — e ainda “desconta” seu próprio uso de Memória. — Acontece que o free não “desconta” o peso do KSysguard, e por isso indica um número maior do que ele.
Acima - A simples abertura do KSysguard elevou o uso de Memória RAM de 865 MiB para 1046 MiB (+181 MiB), segundo o cálculo “novo” — ou de 428 MiB para 531 MiB (+103 MiB), segundo o “cálculo muito antigo” do free.
O valor de 0,48 GiB indicado pelo KSysguard equivale a 492 MiB — menos que os 531 MiB indicados pelo free (-39 MiB).
Plasma System Monitor
 |
| Plasma System Monitor utiliza o “cálculo novo” |
Ao fechar o KSysguard, o uso de Memória RAM caiu para 962 MiB, segundo o “cálculo novo” — cerca de 100 MiB acima dos 865 MiB iniciais.
Portanto, quando abri o Plasma System Monitor, já parti de um patamar um pouco mais elevado.
Acima - O novo Plasma System Monitor indicava uso de 1,1 GiB de Memória RAM — valor exato dos 1128 MiB indicados pelo “cálculo novo” (1,1 GiB).
Gnome System Monitor
 |
| Gnome System Monitor utiliza o “cálculo novo” |
Ao fechar o Plasma System Monitor, o uso de Memória RAM também não volta ao que era logo no início da sessão. — Mesmo assim, o Gnome System Monitor parece “pesar” menos do que as 2 ferramentas do KDE.
Acima - O Gnome System Monitor indica uso de 1,0 GiB — valor muito próximo aos 1000 MiB indicados pelo “cálculo novo” (0,98 GiB).
Um minuto após fechar o Gnome System Monitor, o uso de Memória RAM baixou para 974 MiB, segundo o “cálculo novo” — cerca de 110 MiB acima dos 865 MiB logo após a inicialização. — Este foi o “saldo” de abrir e fechar as 3 ferramentas GUI, uma após outra, pois o sistema guarda parte desses aplicativos em Memória Cache, para evitar nova leitura de disco e abrir mais rápido da próxima vez.
Terminais
O “peso” de qualquer aplicação GUI sempre interfere naquilo que pretende medir — uso de Memória RAM, uso de CPU etc. — por isso desde 2016 optei por usar o Conky, que tem baixíssimo uso de recursos.
Mesmo a abertura de um emulador de Terminal já altera significativamente o uso de Memória RAM. — Além disso, diferentes DEs usam emuladores de Terminal mais “leves” ou mais “pesados” — o que também torna enganosa a comparação entre diferentes distros e DEs, mesmo quando pensamos estar usando “apenas uma ferramenta CLI”, como free, htop, Neofetch etc.
- Para realmente usar “só a ferramenta CLI”, deixe o DE em repouso — e use a ferramenta CLI em um “terminal tty” — tty2, por exemplo.
_______________________
• Publicado em Outubro 2020 e atualizado até Junho 2024 (histórico).
— … ≠ • ≠ … —
Ferramentas &tc.
- Neofetch parou? Viva o Fastfetch!
- Conky altera o cálculo da Memória RAM usada
- Transição para hardware UEFI-GPT
- Speedtest de banda larga de “200 megas”
- Conky - monitor do sistema
- Consertando pequenos problemas do Gimp 2.10
- Pré-visualização de arquivos no Dolphin
- Limpeza do Cooler da CPU
- Escolhendo Grub entre vários Linux
- Teste de memória com o Memtest86
- De volta ao Gnome-screenshot
- Konqueror como gerenciador de arquivos
- Substituição da fonte de energia do computador
- Facebook sobrecarrega visitar e compartilhar “Páginas”
- Corrigindo pontos de montagem no Linux Mint 18 KDE
- Política de Kernel do Linux Mint vs. Kubuntu, KDE Neon & Debian
- KDE “light” eliminando o PIM
- Conky - configuração em andamento
- Google Earth sem placa 3D no Xenial
- Linux ficou sem Administrador. Que fazer?
- Particionamento de disco para vários Linux
- Padronizando PrintScreen no Linux (com Shutter) e no Windows
- Montagem automática de partições adicionais (Cinnamon e Gnome)
- Boot com “Live USB” (Pendrive) do Linux Mint Cinnamon
- Repositórios de software Linux e gerenciador de pacotes Synaptic
- Monitorando a temperatura da CPU no Linux e Windows
- Conversão em massa de TIFF em JPEG
- Meu Wi-Fi parou de funcionar. E agora?
- Cópia de artigos da mídia para citação
- Lua, Júpiter e Vênus em ISO 1600
- Como se livrar do SPAM da Claro que te interrompe de 30 em 30 segundos
- Quantas pessoas cabem na Avenida Paulista?
- A batalha da Comunicação no Facebook
- O Aeroporto de Cláudio documentado no Google Earth
- O apagão do Facebook não será noticiado
- Blog, microblog e redes sociais
- Adeus ao Orkut
- Bookmark para encontrar um post “favorito” no Facebook
- Sincronização do Google Chrome
- Fotos em alta resolução no Facebook
- Sincronizando pastas de documentos entre Linux e Windows
- Dual-boot, Linux, Windows e Grub-customizer
- Listas, Grupos, Fóruns, Comunidades
- Mandar fotos por email para Grupos do Facebook
- Limitando emails de notificação do Facebook
- Conexão 3G pelo “chaveirinho” da TIM
